Optimierung des Linux-OOM-Killers für VPS

Der Linux OOM Killer ist das letzte Mittel des Kernels, wenn der Speicher knapp wird: Er wählt einen Prozess aus und beendet ihn, um das System am Laufen zu halten. Auf einem VPS, wo der Arbeitsspeicher knapp ist und es keine Ausweichmöglichkeiten gibt, ist die Standardwahl oft die falsche. Ihre Datenbank wird beendet, ein lang laufender Worker überlebt, und Sie müssen selbst herausfinden, warum. Dieser Leitfaden behandelt, wie der OOM-Killer Prozesse bewertet, wie Sie diese Bewertung zugunsten Ihrer kritischen Dienste beeinflussen können und wie Sie cgroups einsetzen, damit ein einzelner außer Kontrolle geratener Prozess nicht den Rest des Systems mit sich reißt.

Wie der OOM-Killer ein Opfer auswählt

Wenn der Kernel durch das Verdrängen von Seiten aus dem Seiten-Cache oder durch Auslagerung nicht genügend Speicher zurückgewinnen kann, ruft er den OOM-Killer auf. Jeder Prozess hat einen oom_score Wert zwischen 0 und 1000, der sich hauptsächlich aus seiner Resident Set Size (RSS) und der Swap-Nutzung ableitet. Der Prozess mit dem höchsten Wert erhält ein SIGKILL.

Die RSS dominiert die Berechnung, weshalb der Kill fast immer den größten Speicherverbraucher trifft. Das ist häufig Ihre Datenbank, Ihr Anwendungsserver oder welcher langlebige Prozess auch immer die nützlichste Arbeit leistet. Der Prozess, der die Zuweisung tatsächlich ausgelöst hat, der „Invoker“, wird selten beendet.

Es gibt zwei Arten von OOM-Ereignissen, die Sie unterscheiden müssen:

• Global OOM: Dem Host (oder Ihrem VPS insgesamt) geht der RAM und der Swap aus. Der Kernel scannt jeden Prozess und beendet den Prozess mit der höchsten Punktzahl.
• Cgroup-OOM: Eine bestimmte Cgroup hat ihr Speicherlimit erreicht. Der Kernel beendet nur Prozesse innerhalb dieser Cgroup, selbst wenn der Rest des Systems über freien Speicher verfügt.

Wenn Sie systemd-Unit-Limits konfiguriert haben oder Container ausführen, werden die meisten Ihrer OOM-Ereignisse cgroup-OOMs sein. Das ist gut so: Der Schadensradius bleibt begrenzt.

Speicherbelastung erkennen, bevor es zum Systemabsturz kommt

OOM-Ereignisse treten fast nie plötzlich auf. In der Regel gibt es zunächst ein Zeitfenster, in dem der Druck zunimmt, und das Ziel der Überwachung ist es, dies innerhalb dieses Zeitfensters zu erkennen.

free -h gibt Ihnen die Systemansicht. Die relevante Spalte ist available, nicht free: Sie berücksichtigt den wiederverwendbaren Seiten-Cache und spiegelt wider, was Sie tatsächlich ohne Swapping zuweisen können. Halten Sie MemAvailable etwa 10 bis 15 Prozent MemTotal bei Spitzenauslastung.

Für die Zuordnung pro Prozess sortieren Sie nach RSS:

ps aux --sort=-%mem | head -10

Oder verwenden Sie htop und sortieren Sie nach RES. Die hier angezeigten Werte fließen direkt in die Bewertung des Kernels ein, sodass die obersten Einträge die wahrscheinlichsten OOM-Ziele sind.

Bei Kerneln ab Version 4.20 ist die „Pressure Stall Information“ das Frühwarnsystem, das es sich lohnt, in die Überwachung einzubinden:

cat /proc/pressure/memory

Die some avg10 Zahl gibt den prozentualen Anteil der Zeit an, in der mindestens eine Aufgabe in den letzten zehn Sekunden beim Warten auf Speicher ins Stocken geraten ist. Unter 5 Prozent ist alles in Ordnung. Anhaltende Werte über 10 Prozent bedeuten, dass das System reale Zeit mit der Speicherfreigabe verbringt, und ein OOM-Kill ist wahrscheinlich.

Swap-Thrashing wird in vmstat 1 als Wert ungleich Null si und so Spalten, die über einen längeren Zeitraum anhalten. Ein geringer Anteil an residentem Swap ist harmlos. Ständiges Ein- und Auslagern ist es nicht.

Schutz kritischer Prozesse mit oom_score_adj

Der vom Kernel berechnete Wert kann pro Prozess durch oom_score_adjauf einer Skala von -1000 (immun) bis +1000 (töte mich zuerst) prozessspezifisch angepasst werden. Die Anpassung wird direkt zur Endpunktzahl addiert.

Für eine einmalige Änderung bei einem laufenden Prozess:

echo -500 | sudo tee /proc/$(pidof sshd)/oom_score_adj

Für alles, was über Neustarts hinweg bestehen bleiben soll, legen Sie es in der systemd-Einheit fest. Das ist der richtige Ort für sshd, Ihre Datenbank und alles andere, was Sie nicht verlieren dürfen:

[Service]
OOMScoreAdjust=-900

Sinnvolle Standardwerte für den Start:

• sshd: -1000. Wenn du während einer Speicherkrise den Fernzugriff verlierst, wird die Wiederherstellung erheblich erschwert.
• MySQL, PostgreSQL, Redis: -800 bis -900. Starker Schutz, ohne sie in einer wirklich katastrophalen Situation völlig unantastbar zu machen.
• Anwendungs-Worker, Batch-Jobs, Cron-Aufgaben: +100 bis +500. Dies sind die Prozesse, die Sie lieber beendet sehen würden als Ihre Datenbank.

Stellen Sie nicht alles auf -1000 ein. Wenn nichts beendet werden kann, gerät der Kernel schließlich in Panik oder friert ein, was noch schlimmer ist.

Begrenzung des Speichers mit cgroups und systemd

Das Anpassen der Scores beeinflusst, wer beendet wird. Cgroups beeinflussen, ob die globale Beendigung überhaupt stattfindet. Indem Sie jedem Dienst eine feste Obergrenze zuweisen, verlagern Sie Speicherausfälle in eine einzelne Cgroup, anstatt zuzulassen, dass ein einzelner Prozess den gesamten VPS auslastet.

In einer systemd-Unit-Datei:

[Service]
MemoryHigh=400M
MemoryMax=512M
OOMPolicy=stop
Restart=on-failure
RestartSec=5s

MemoryHigh ist eine weiche Drosselung: Der Kernel gewinnt ab diesem Punkt aggressiv Seiten aus der cgroup zurück, beendet jedoch nichts. MemoryMax ist die harte Obergrenze. Wenn die cgroup versucht, darüber hinaus Speicher zuzuweisen, beendet der Kernel einen Prozess innerhalb der cgroup. Mit Restart=on-failure wird der Dienst sofort wieder gestartet.

Bei cgroup v2 (Ubuntu 22.04 und höher, aktuelle Debian-Versionen, RHEL 9) memory.oom.group werden alle Prozesse in der cgroup gemeinsam beendet, anstatt verwaisten Prozesse zurückzulassen. Nützlich für Dienste mit mehreren Prozessen wie PHP-FPM-Pools, bei denen eine nur teilweise beendete Gruppe Fehlverhalten verursacht.

Einige anwendungsspezifische Hinweise, die es zu beachten gilt:

• PHP-FPM: Setze pm = ondemand auf kleinen VPS-Instanzen und dimensionieren pm.max_children auf den durchschnittlichen RSS-Wert pro Worker ein, nicht auf den Standardwert. Ein Pool, der auf 4 GB Spielraum auf einem 2-GB-VPS ausgelegt ist, wird beim ersten Füllen einen OOM-Fehler auslösen.
• Node.js: Begrenze den V8-Heap mit --max-old-space-size=512 (in MB). Ohne diese Begrenzung wächst Node munter weiter, bis der Kernel eingreift.
• MySQL und PostgreSQL: innodb_buffer_pool_size und shared_buffers sollten ausreichend Spielraum für den Seiten-Cache des Betriebssystems, den Verbindungsspeicher und alle anderen Nutzer auf dem Server lassen. Die Standardeinstellungen gehen von einem dedizierten Server aus.

Lesen der Protokolle nach einem OOM-Ereignis

Wenn der OOM-Killer ausgelöst wird, speichert der Kernel einen detaillierten Bericht im Ringpuffer. Rufen Sie ihn mit folgendem Befehl ab:

dmesg -T | grep -iE 'killed process|out of memory'
journalctl -k --grep='Out of memory'

Der Block, den Sie sorgfältig lesen sollten, beginnt mit dem Aufrufer und endet mit dem Opfer. Der Kernel gibt eine vollständige Aufgabenliste mit dem RSS, der Swap-Nutzung und dem endgültigen oom_score_adj. Drei Dinge sind besonders zu beachten:

• Die Beschränkung. CONSTRAINT_NONE bedeutet einen globalen OOM, CONSTRAINT_MEMCG bedeutet, dass eine cgroup ihr Limit erreicht hat. Die Lösung ist in jedem Fall unterschiedlich.
• Free swap. Wenn dies 0kB, waren sowohl RAM als auch Swap erschöpft. Fügen Sie entweder Swap hinzu, erhöhen Sie MemoryMax für den Verursacher erhöhen oder die Parallelität reduzieren.
• Die Punktzahl des Opfers im Vergleich zu allen anderen. Wenn die Punktzahl des Opfers nicht wesentlich höher ist als die der nächsten paar Prozesse, oom_score_adj Werte leisten nicht genug. Vergrößern Sie den Abstand.

Speziell bei cgroup-OOMs befindet sich der Kill-Zähler memory.events innerhalb der cgroup:

cat /sys/fs/cgroup/system.slice/mysql.service/memory.events

Ein steigender oom_kill Zahl bedeutet, dass der Dienst wiederholt an seine Grenze stößt. Das ist ein Signal, MemoryMax, die Arbeitslast zu analysieren oder den Dienst auf einen größeren Tarif umzustellen, anstatt ihn endlos neu zu starten.

Zusammenfassung

Beim Optimieren des OOM-Killers geht es nicht darum, ihn ganz zu deaktivieren. Es geht darum, zu steuern, welcher Prozess den Preis zahlt, wenn der Speicher knapp wird, und den Auswirkungsbereich zu verringern, wenn dies geschieht. Das Muster, das sich in der Produktion bewährt hat:

• Schützen Sie die Dienste, deren Ausfall Sie sich nicht leisten können, insbesondere sshd und Ihre Datenbanken.
• Begrenzen Sie alles andere MemoryMax in einer systemd-Einheit, damit ein einzelner Ausreißer nur einen Neustart und keinen Ausfall bedeutet.
• Beobachten Sie den PSI und MemAvailable , anstatt darauf zu warten, dmesg , dass es Ihnen die Situation erst im Nachhinein erklärt.
• Lassen Sie 15 bis 20 Prozent des Arbeitsspeichers als Puffer frei. Eine Optimierung kann einen VPS nicht kompensieren, der für die Arbeitslast einfach zu klein ist.

Wenn Ihr Speicherbedarf strukturell bedingt und nicht konfigurierbar ist, benötigen Sie mehr RAM oder schnelleren, durch Swap-Speicher unterstützten Speicher. Die VPS-Tarife von FDC Servers laufen auf AMD EPYC mit NVMe-Speicher, wodurch Lesevorgänge über den Swap-Speicher schnell genug bleiben, sodass kurze Speicherengpässe nicht zu Systemabstürzen eskalieren.