Lösung des Out-of-Memory-Killer-Rätsels

Wir haben kürzlich den IBM Instana Crash Detector eingeführt, der abnormale Prozessabbrüche auf allen Linux-Maschinen mit Linux-Kernel 4.8 oder höher automatisch erkennt und meldet. Die IBM Instana-Plattform nutzt die eBPF-Funktionen (Extended Berkeley Packet Filter) des Linux-Kernels, um sich in den Kernel selbst einzubinden und auf Prozessabbrüche zu achten. Alle abnormalen Beendigungen werden dem Host-Agenten gemeldet, der sie mit den von ihm überwachten Prozessen zur Vermeidung von Störungen durch nicht relevante Prozesse vergleicht und dann die Informationen an das IBM Instana-Backend sendet. Es hat sich gezeigt, dass diese Funktion für unsere Kunden bei der Behebung von Problemen einen entscheidenden Vorteil darstellt.

Mit Crash Detector liefert die IBM Instana-Software die kritischen Daten für viele der Probleme, die die Leistung der Anwendungen unserer Kunden beeinträchtigen. Wir erweitern diese Funktion nun, indem wir den Crash Detector um Out-of-Memory-Killer-Ereignisse (OOM-Killer) erweitern. Aufgrund seiner Relevanz für containerbasierte Anwendungen ist dies eine äußerst wertvolle Ergänzung.

Die Cloud mag den Anschein erwecken, als stünde Ihnen bei ausreichendem Budget unendlich viel Rechenleistung zur Verfügung. Diese Rechenleistung ist jedoch nur in Teilen verfügbar. Hosts (physisch und virtuell), Container und Funktionen – sie alle haben Beschränkungen bei der Zuweisung von Speicherplatz.

Unter Linux ist der OOM-Killer (Out-of-Memory) ein Prozess, der dafür verantwortlich ist, dass andere Prozesse nicht den gesamten Speicher des Hosts ausschöpfen. Wenn ein Prozess versucht, mehr Speicher zuzuweisen, als verfügbar ist, erhält der Prozess mit dem insgesamt höchsten Badness-Score, der sich z. B. danach richtet, wie viel Speicher er über das zulässige Maß hinaus zuweist, ein OOM-Signal. Das bedeutet im Grunde genommen: „Sie liegen völlig daneben. Beenden Sie den Prozess oder bringen Sie einige der untergeordneten Prozesse zum Beenden, oder die Lichter gehen aus.“

Beachten Sie, dass der Prozess, der das OOM auslöst, möglicherweise nicht der Prozess ist, der das OOM-Signal empfängt. Eine Anwendung, die in letzter Zeit ihre Speichernutzung nicht erhöht hat, erhält plötzlich ein OOM-Signal, weil zu viele andere Anwendungen auf demselben Host gestartet wurden.

Die Mechanik eines OOM-Signals klingt hart, ist jedoch ein sehr effektiver Mechanismus zur Vermeidung einer Speichererschöpfung auf Hosts, insbesondere bei Anwendungen, die nicht korrekt dimensioniert sind, oder bei zu vielen parallel laufenden Anwendungen (d. h. die Hosts sind nicht korrekt für die Workload dimensioniert).

Für containerbasierte Plattformen wie Kubernetes, Cloud Foundry und Nomad ist die Nutzung des Arbeitsspeichers – sowohl im Hinblick auf die angemessene Dimensionierung von Anwendungen als auch im Hinblick darauf, wie viele Anwendungen gleichzeitig auf einem Host ausgeführt werden sollen – noch wichtiger. Im Allgemeinen plant man nicht im Detail, welche Anwendungen auf einem bestimmten Knoten ausgeführt werden. In vielen Konfigurationen werden Container vom Orchestrator nach einer bestimmten Logik zugewiesen. Die Durchsetzung eines maximalen Speicherverbrauchs ist für Container und Kontrollgruppen (cgroups), die Grundlage praktisch jeder Containertechnologie unter Linux, von entscheidender Bedeutung. Diese verwenden auch das OOM-Killersystem, um sicherzustellen, dass Prozesse, die in derselben Gruppe (d. h. einem Container) ausgeführt werden, nicht mehr Speicher zuweisen, als sie dürfen. Wenn die Prozesse in Ihren Containern versuchen, mehr Arbeitsspeicher zuzuweisen, als sie dürfen, werden einige von ihnen beendet, was oft auch ihre Container zum Absturz bringt.

In großem Maßstab ist alles schwieriger, auch die Größenanpassung. Je mehr Container Sie in Ihren Umgebungen ausführen, desto schwieriger ist es zu verstehen, wann, wie und warum einige von ihnen ausfallen. OOM-Killer können ungesunde Situationen für Ihre Anwendungen schaffen, in denen ständig irgendwo etwas abstürzt und dann neu gestartet wird. Dadurch entstehen für Ihre Endbenutzer kontinuierlich viele Fehler, die Ihre SLOs (Service Level Objectives) verzerren und sehr schwer zu beheben sind.

Die Ermittlung der Gründe für die Beseitigung eines einzelnen Prozesses durch OOM-Killer hängt stark von der verwendeten Technologie ab. Einige Softwarepakete protokollieren es in ihren eigenen Protokollen. Oder Sie führen einen Befehl wie den folgenden auf Ihren Hosts, d. h. auf jedem von ihnen, aus:

     #CentOS
     grep -i "out of memory" /var/log/messages
     #Debian / Ubuntu
     grep -i "out of memory" /var/log/kern.log

Das sieht harmlos aus, ist aber definitiv nicht die Art von Aufgabe, die Sie in Ihrer Produktionsflotte ausführen wollen, um zu verstehen, warum MySQL um 3 Uhr morgens wieder einmal abgestürzt ist. Vor allem, wenn es sich um eine Vermutung handelt, denn nichts anderes scheint zu erklären, warum der Datenbankprozess nicht mehr vorhanden ist.

Anders ausgedrückt: Der OOM-Killer ist ein System mit großer Bedeutung und Wirksamkeit für die Zuverlässigkeit, das keine ausreichende Observability Obietet. Die IBM Instana-Plattform hilft jedoch bei der Behebung dieses Problems.

Aufbauend auf der eBPF-Grundlage, die den Crash Detector ermöglicht hat, verfügt die IBM Instana-Software nun über einen sofort einsatzbereiten OOM-Killer-Detektor. Wird Ihr Prozess von der IBM Instana-Software überwacht, erhält er in Echtzeit ein OOM-Signal. Nicht nur, dass es passiert ist, sondern auch, wie die Situation gelöst wurde (d. h. welcher Prozess beendet wurde).

Wie bei den meisten IBM Instana-Funktionen müssen Sie nur den IBM Instana-Hostagenten installieren und können dann zusehen, wie der OOM-Killer sein Werk vollbringt. Es wird auch angezeigt, wie viel Speicher der beendete Prozess zum Zeitpunkt des Ereignisses belegt hat, damit Sie verstehen können, warum er vom OOM-Killer als „schlecht“ markiert wurde.

Die Ermittlung, wie und warum ein Prozess abgebrochen wurde oder warum ein Prozess mit einem OOM-Killer beendet wurde, kann ohne die richtigen Tools Stunden, wenn nicht sogar Tage dauern. Mit dem IBM Instana Crash Detector wissen die Benutzer nun sofort die Ursache für jeden abnormalen Prozessabbruch und jeden erfolgreichen OOM-Killerprozess.

Müssen Sie verstehen, warum ein Container zerstört wurde? Kein Problem. Mit dem OOM-Killer von IBM Instana Crash Detector wissen Sie, dass Ihre Java Virtual Machine (JVM) beim Ausführen eines sehr wichtigen Batch-Jobs möglicherweise mehr Ressourcen als zulässig zugewiesen hat. Vielleicht müssen Sie aber auch die Ursache für die vielen fehlgeschlagenen PHP-Anfragen (Hypertext Preprocessor) der für das Verschwinden Ihrer Datenbank ermitteln. Auch hier haben Sie mit dem OOM-Killer des IBM Instana Crash Detector sofortigen Zugriff auf die Grundursache dieser Probleme.

Installieren Sie den IBM Instana-Agenten noch heute auf Ihrem Linux-Betriebssystem, um sich und Ihren DevOps-Teams Zeit bei der Behebung von OOM-Killer-Ereignissen zu sparen. Wenn Sie noch keine IBM Instana-Instanz haben, können Sie mit einer kostenlosen Testversion erfahren, wie der IBM Instana Crash Detector mit OOM-Killererkennung funktioniert.