Ist dir aufgefallen, dass unsere Server Ende 2024 öfters Probleme hatten? Uns auch! Die Server blieben gelegentlich stehen, manchmal erwachten sie von selbst wieder zum Leben und manchmal musste ein Neustart durchgeführt werden, um sie wiederherzustellen. Das Seltsame daran? Unsere Überwachung ergab keine offensichtliche Ursache für diese Aussetzer.
Typische Serverprobleme haben naheliegende Ursachen – eine problematische Kundenanwendung, fehlerhafte Netzwerk- oder Virtualisierungseinstellungen oder Hardwareprobleme. Diesmal war es anders. Die üblichen Diagnoseschritte ergaben keinen eindeutigen Hinweis auf die Grundursache. Gleichzeitig verschlechterte sich die Stabilität unserer Infrastruktur immer weiter.
Wir erkannten, dass wir mehr als nur routinemäßige Fehlerbehebung benötigten. Wir haben eine spezialisierte Arbeitsgruppe zusammengestellt, die nicht nur unsere eigenen Experten, sondern auch externe Kernel-Entwickler und Spezialisten von Software-Anbietern wie Virtuozzo einbezog. Wenn die üblichen Lösungsansätze nicht richtig sind, müssen wir tiefer graben – viel tiefer.
Auf der Suche nach Antworten
Einige technische Probleme kündigen sich laut an. Andere, wie dieses, halten sich im Verborgenen. Unsere Arbeitsgruppe begann damit, alle möglichen Aspekte zu untersuchen – verschiedene Hardwaremarken, verschiedene Rechenzentren, Benutzerprofile, Arbeitslasten. Nichts schien auf einen klaren Übeltäter hinzuweisen.
Etwa 20 % unserer Supportanfragen betrafen Probleme mit der Serverkonfiguration, eine Zahl, die unsere Aufmerksamkeit erregte. Normalerweise zeigen Konfigurationsprobleme klare Muster. Aber diese Tickets beschrieben verschiedene Symptome, die zum gleichen Ergebnis führten: nicht reagierende Server, die Neustarts benötigten.
Theorien prüfen
Wir prüften Hypothesen über Hardware. Könnte es spezifisch für bestimmte Servermarken sein? Die Probleme traten sowohl bei Lenovo-, Dell- als auch HPE-Systemen auf und hatten auch nichts mit Festplattenproblemen zu tun. Vielleicht besondere Standorte von Rechenzentren? Kein Muster dort. Wir betrachteten verschiedene Versionen von Betriebssystemen und Virtualisierungssoftware, aber es gab auch keinen klaren Grund. Selbst als wir analysierten, wie unterschiedliche Kunden ihre Server nutzten, konnten wir keine bedeutenden Muster erkennen.
Der erste Durchbruch kam, als wir die Proxmox- und die verwendete Linux-Kernelversion auf unseren Vhost-Servern änderten. Die Stabilität verbesserte sich insgesamt, aber jetzt begannen die Server, völlig andere Leistungsprobleme zu haben. Unsere Taskforce grub weiter und untersuchte die Muster des Speichermanagements.
Speichermanagement verstehen
Der Speicher-Tanz
Bevor wir mit unserer Geschichte fortfahren, lasst uns erklären, was Speichermanagement ist.
In Produktionsumgebungen ist das Speichermanagement ein sorgfältiger Balanceakt. Die CPU vollführt ständig einen komplexen Tanz, indem sie Daten zwischen RAM und Swap verschiebt. Aktive Anwendungen bleiben im schnellen RAM, während inaktive anhand von Nutzungsmustern in den langsameren Swap-Speicher verschoben werden.
Diese Koordination passiert tausende Male pro Sekunde, normalerweise ohne dass es jemand bemerkt. Es ist ein branchenüblicher Standard, der seit Jahrzehnten im Cloud-Computing verwendet wird. Dieser RAM-plus-Swap-Ansatz eignet sich für alles, von kleinen WordPress-Sites bis hin zu umfangreichen Datenbanken und darüber hinaus.
Das ZRAM-Versprechen
Hier kommt ZRAM ins Spiel – eine Standardfunktion des Linux-Kernels, die die Speicherverwaltung noch effizienter machen soll. Durch die Komprimierung der Daten direkt im RAM bietet er 25% mehr Kapazität. Stell dir das so vor: Während Swap verwendet wird, um weniger genutzte Daten außerhalb des RAM zu halten, komprimiert ZRAM die Daten, um mehr davon im RAM zu halten.
Den wahren Übeltäter aufspüren
Jetzt, da wir etwas Kontext haben, kehren wir zu unserer Untersuchung zurück. Im Laufe der Zeit, während wir einige Stabilitätsprobleme durch Systemupdates behoben, führten wir ZRAM in unserer Infrastruktur ein. Zunächst schien alles in Ordnung zu sein. Dann begannen unsere Überwachungstools, ungewöhnliche Muster in den Eingabe-/Ausgabeoperationen zu erfassen.
Das Problem war nicht sofort erkennbar. Die Server liefen bis zu einer bestimmten Speicherkonstellation normal. Der kritische Moment kam, als Systeme volle Kapazität erreichten und sowohl ZRAM als auch Swap-Speicher gleichzeitig handhaben mussten. Wir stellten fest, dass physisches RAM mit Swap gut funktionierte, ebenso wie physisches RAM mit ZRAM. Wenn jedoch sowohl die Komprimierung als auch die Auslagerung aktiviert waren, trat das Server-Einfrieren-Problem auf.
Unsere Debug-Protokolle und Datenausgaben enthüllten die ganze Geschichte. Das Debugging auf Kernel-Ebene zeigte, dass die Übergabe zwischen RAM (komprimiert mit ZRAM) und Swap, wenn beide Kapazität erreichten, nicht korrekt funktionierte. Anstatt Daten reibungslos zwischen komprimiertem RAM und Swap-Speicher zu verschieben, froren die Systeme vollständig ein. Die Latenzmuster in unseren Debug-Ausgaben deuteten auf ein grundlegendes Problem mit diesem Ansatz des Speichermanagements hin.
Bis Dezember 2024 hatten wir genug Beweise, um einen entscheidenden Schritt zu machen. Wir deaktivierten ZRAM in allen Systemen. Die Auswirkungen waren sofort und klar: die mysteriösen Eingabe-/Ausgabe-Probleme verschwanden. Noch wichtiger ist, dass die mysteriösen Systemeinfrierungen, die unsere Kunden und uns selbst frustriert hatten, drastisch zurückgingen.
Mission erfüllt.
Wir hoffen, dass die Erkenntnisse, die wir über das Verhalten von ZRAM gewonnen haben, anderen Anbietern, die vor ähnlichen Herausforderungen stehen, helfen können.
Ausblick
Die Aufrechterhaltung der Systemstabilität der Serverinfrastruktur ist eine kontinuierliche Aufgabe. Die Deaktivierung von ZRAM hat zwar die Leistungseinbußen im Jahr 2024 behoben, aber wir suchen weiter nach anderen Möglichkeiten, um eine noch stabilere Umgebung zu schaffen. Wir verbessern auch unsere Infrastruktur: Wir rüsten unsere Hosts-Flotte auf neue AMD Turin-Prozessoren auf, die neuesten CPUs, die eine noch effizientere Speicherverwaltung bieten.
Wir können Ihnen zwar nicht versprechen, dass es nie zu Ausfallzeiten kommen wird, aber wir können Ihnen versprechen, dass wir uns ständig optimieren und verbessern, damit Ihre Workloads rund um die Uhr an 365 Tagen im Jahr reibungslos laufen.