OpenSource von Facebook für die Memory-Verwaltung Der Facebook-Ersatz für den Standard-OOM-Killer im Linux-Kernel

Egal, ob Hyperscaler oder KMU, das Problem trifft alle: Server Out-of-Memory (OOM). Rien na va plus. Die gestarteten Prozesse belegen zu viel Speicher. Diese gehören abgemurkst, um Platz zu erzwingen. Facebook veröffentlicht nun als Open Source „oomd“, einen neuen Userspace-OOM-Killer.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

DataCore Software GmbH

Fujitsu Technology Solutions GmbH

Facebook Germany GmbH

oomd kommt zum Einsatz, wenn ein Workload den gesamten verfügbaren Systemspeicher verbraucht beziehungsweise bevor der Fall eintritt. Auf der Seite, auf der Daniel Xu von Facebook das Tool vorstellt, heißt es: „Wir haben oomd in der Produktion bei Facebook entwickelt, eingesetzt und festgestellt, dass die Häufigkeit von Livelocks abnimmt, die von Build-Servern über Rack-Switches bis hin zu gemeinsam genutzten Compute-Ressourcen reichen.“ Er bezeichnet das Tool als „zuverlässigen und effektiven Ersatz“ für den Standard-Linux-Kernel-OOM-Killer.

Bildergalerie

Laut Xu gehören zum Tool zwei Kernkomponenten: Ein Pre-OOM-Monitoring, das den OOM-Vorgang sichtbar macht, bevor die Arbeitslast bedrohlich wird, sowie ein Plugin-System, das das Durchsetzen und Definieren von Richtlinien ermöglicht, um gezielt gegen Memory-fressende Workloads vorzugehen.

Die Ausgangslage

Der Hintergrund für die Eigenentwicklung eines OOM-Killers sei das anwachsende Ökosystem aus Anwendungen und Infrastrukturen bei Facebook gewesen, die auf Hosts basieren, auf denen Linux läuft. Immerhin sei die Facebook-Gemeinde auf mehr als 2,2 Milliarden Menschen angewachsen und die IT-Landschaft umfasse riesige Applikationen wie „News Feed“, „Messenger“, „Instagram“, „Whatsapp“ und „Oculus“, die auf Millionen von Servern laufen, die in geografisch verteilten Rechenzentren stehen.

Und Facebook trifft es wie jedes Unternehmen mit eigener IT: Mit der Skalierung der Infrastruktur besteht ein zunehmender Anteil der Maschinen und Netzwerke aus mehreren Generationen. Einer der Effekte ist ebenfalls hinlänglich bekannt: Das Einspielen eines neuen Release oder eine Konfigurationsänderung kann dazu führen kann, dass ein System auf der einen Maschine rund läuft, auf einer anderen aber ein Out-of-Memory-Problem auftritt.

Laut Xu funktionierte der traditionelle Linux-OOM-Killer in einigen Fällen gut, aber in anderen Fällen zu spät. Der Effekt: Das System gelangt für eine unbestimmte Zeit in einen Livelock. Er schreibt: „Wir finden, dass oomd schneller reagiert, weniger starr und zuverlässiger ist. In der Praxis haben wir gesehen, wie 30-minütige Livelocks komplett verschwunden sind.“

Ein neuer Ansatz für OOMs

Ausgangspunkt für den Facebook-Ansatz ist die gewollte Speicherüberlastung, Memory Overcommit. Dabei handelt es sich um gängige Technik zur Erhöhung der Speicherauslastung – es wird mehr Speicher für Prozesse allokiert als der gesamte verfügbare Systemspeicher hergibt. Sie funktioniert auf der Annahme, dass nicht der gesamte zugewiesene Speicher für die Ausführung von Anwendungen tatsächlich benötigt wird.

Allerdings stimmt das nicht in jedem Fall., so dass wenn die Nachfrage den verfügbaren Speicher übersteigt, der Linux-OOM-Killer versucht, Speicher zurückzugewinnen. Seine Hauptaufgabe dabei: Der Kernel muss so geschützt werden, dass die Maschine quasi am Leben bleibt. Also werden einige Prozesse beendet, ohne Rücksicht auf ihre Wichtigkeit. Das Risiko, das doch etwas Gravierendes dabei ist, besteht.

Dem soll oomd begegnen. Voraussetzung dafür sind „PSI“ und „Cgroup2“.

Pressure Stall Information, kurz: PSI, ist ein Dienstprogramm, das vom Facebook-Ingenieur Johannes Weiner entwickelt hat. Es dient zum Tracking von Systemressourcen: CPU, Speicher und I/O, dient also zur Beobachtung und zum Messen von Auslastung beziehungsweise Nutzung dieser Ressourcen. Xu erläutert: „Wenn PSI in der Produktion eingesetzt wird, stellen wir fest, dass seine Metriken als Barometer für die drohende Ressourcenknappheit dienen und es dem Benutzer ermöglichen, bei Bedarf proaktive Maßnahmen zu ergreifen.“

Bei Cgroup2 handelt es sich um einen Nachfolger von cgroup, einem Linux-Kernel-Mechanismus, der Prozesse hierarchisch organisiert und Systemressourcen entlang der Hierarchie kontrolliert und konfigurierbar verteilt. oomd nutzt die Mechanismen von cgroup2, um sicherzustellen, dass sich jeder Workload angemessen verhält. So meldet cgroup2 zum Beispiel den genauen Ressourcenverbrauch pro Workload sowie die Metadaten der Prozesse. Zudem bestzt Cgroup2 eine PSI-Schnittstelle, die von oomd verwendet wird.

Lösen eines alten Kernelspace-Problems

oomd überwacht nun ständig PSI-Metriken, um festzustellen, ob ein System unter nicht wiederherstellbarer Last steht. PSI alleine aber würde nicht ausreichen, daher überwacht oomd das System auch ganzheitlich. Der Standard OOM-Killer von Linux hingegen konzentriert sich, wie erwähnt, in erster Linie auf die Belange des Kernels.

So kann oomd zugleich flexibler und reaktionsschneller sein. Das Tool kann Korrekturmaßnahmen ergreifen, bevor ein systemweites OOM auftritt. Diese lassen sich über ein Plugin-System konfigurieren, das zudem in der Lage ist, benutzerdefinierten Code auszuführen. Das setzt Admins und Entwickler in die Lage, ein Plugin mit alternativen Strategien anzupassen.

Bildergalerie

oomd verwendet einen generischen Kill-Mechanismus, eine Kill-Liste, die bekannte „Täter", also Prozesse oder Dienste, enthält, die im Falle eines OOMs als erste k.o. gehen sollten. Dafür gibt es zudem Kriterien, die erfüllt sein müssen. Dazu ein Beispiel: Wir ein Hilfsdienst generiert, der In-Memory-Cache für bestimmte Objekte enthält, kann die Kill-Liste von oomd so konfiguriert werden, dass der Cache erst beim Überschreiten einer festgelegten Speichergröße geleert wird (Die dokumentierten Testfälle finden sich in der Bildergalerie).

(ID:45418218)