Speicherdruck unter Linux richtig lesen: free, Swap, OOM-Killer und OOMScoreAdjust

Worum es geht

free zeigt den gesamten, belegten und freien Speicher, den gemeinsam genutzten Speicher (shared), buff/cache und available sowie eine Zeile für Swap. Die Spalte free allein unterschätzt den verfügbaren Spielraum, weil Linux ungenutzten Speicher als Festplatten-Cache verwendet. Die Spalte available schätzt, wie viel Speicher einem neuen Prozess tatsächlich ohne Swapping zugeteilt werden kann, und berücksichtigt dabei freigebbaren Cache. Sind verfügbarer Speicher und Swap erschöpft, wählt der OOM-Killer (Out-of-Memory-Killer) des Kernels einen Prozess aus und beendet ihn, damit das System weiterläuft. Die Aktion wird im Kernel-Log protokolliert und ist mit dmesg oder journalctl -k einsehbar.

Zwei systemd-Unit-Einstellungen beeinflussen dies pro Dienst: OOMScoreAdjust= ist ein Wert von -1000 bis 1000, der in /proc/[pid]/oom_score_adj des Prozesses geschrieben wird und die OOM-Heuristik des Kernels dafür oder dagegen gewichtet, den Prozess zu beenden (ein negativerer Wert macht die Auswahl unwahrscheinlicher). MemoryMax= ist eine harte Obergrenze, die vom cgroup-Controller durchgesetzt wird: Ein Prozess, der sein eigenes Budget überschreitet, wird beendet, bevor der systemweite OOM-Killer überhaupt zwischen voneinander unabhängigen Diensten wählen muss.

Warum es wichtig ist

Ein Dienst, der ohne Fehlermeldung der Anwendung und ohne Crash-Log stirbt, ist ein häufiges Symptom eines OOM-Kills: Der Kernel beendet ihn mit SIGKILL, was die Anwendung weder abfangen noch protokollieren kann. Wer dies mit einem Anwendungsfehler verwechselt, verschwendet Zeit bei der Fehlersuche; wer den freien (free) mit dem verfügbaren Speicher (available) verwechselt, löst Fehlalarme aus oder übersieht echte Probleme.

So wird es angewendet

• free -h lesen und sich nach available richten, nicht nach free; ein kleiner free-Wert bei grossem available-Wert ist normal und unproblematisch.
• Swap-Nutzung prüfen und kontrollieren, ob überhaupt Swap konfiguriert ist (swapon --show); ein System ohne Swap hat weniger Vorwarnzeit, bevor der OOM-Killer eingreift.
• Nach einem unerklärten Absterben eines Dienstes mit journalctl -k | grep -i "out of memory" oder dmesg | grep -i oom nach einem Kill-Eintrag suchen, der den Prozess und seinen Score nennt.
• Für einen Prozess, der als letzter beendet werden soll, in der [Service]-Sektion der systemd-Unit OOMScoreAdjust=-500 (oder ähnlich) setzen, für einen verzichtbaren Batch-Job, der zuerst beendet werden soll, einen positiven Wert.
• MemoryMax= bei Diensten mit bekanntem maximalem Speicherbedarf setzen, damit ein Speicherleck in einem Dienst nicht unabhängige Dienste auf demselben Host aushungert; mit systemctl show <unit> -p MemoryMax -p OOMScoreAdjust überprüfen.

Stolpersteine

• Jeden Prozesstod als Codefehler behandeln, ohne zuvor das Kernel-Log nach einem OOM-Eintrag zu prüfen.
• OOMScoreAdjust=-1000 (praktisch OOM-immun) für einen Dienst setzen, der dadurch ein echtes Speicherleck verdeckt, weil der Kill stattdessen einen anderen Prozess trifft und das Problem nicht sichtbar wird.
• Vergessen, dass MemoryMax= einen OOM-Kill auf cgroup-Ebene für die eigenen Prozesse des Dienstes auslöst; dieser sieht in dmesg identisch zu einem systemweiten OOM-Kill aus, hat aber eine andere, engere Ursache.