Den Load Average lesen und den OOM-Killer verstehen

Worum es geht

Die ersten drei Felder von /proc/loadavg sind gemäss proc_loadavg(5) die Anzahl Jobs in der Run-Queue (Zustand R) oder wartend auf Disk-I/O (Zustand D), gemittelt über 1, 5 und 15 Minuten. Die Zahl ist kein Prozentwert: Sie ist nur im Verhältnis zur Anzahl CPUs (nproc) aussagekräftig. Da auch Tasks im D-Zustand mitgezählt werden, erhöht ein hängender NFS-Mount oder eine gesättigte Disk den Load, während die CPUs untätig bleiben.

Die Speicher-Dokumentation des Kernels beschreibt die andere Hälfte. Linux überbucht Speicher standardmässig (vm.overcommit_memory 0: offensichtliche Überbuchungen werden abgelehnt, alles andere wird gewährt). Schlägt eine Allokation fehl und kann durch Reclaim nicht genug freigegeben werden, durchsucht der OOM-Killer die Task-Liste und beendet die Task mit dem höchsten Badness-Score, normalerweise den grössten Speicherverbraucher – ausser oom_kill_allocating_task ist gesetzt, dann wird die Task beendet, die den Zustand ausgelöst hat. proc_pid_oom_score_adj(5) erklärt, dass /proc/<pid>/oom_score_adj den Score im Bereich von -1000 (OOM_SCORE_ADJ_MIN, wird nie beendet) bis +1000 verschiebt.

Warum es wichtig ist

Beide Zahlen werden routinemässig falsch gelesen. Ein Load von 8 auf einem Host mit 8 CPUs bedeutet volle Auslastung, auf einem Host mit 2 CPUs bedeutet es massives Anstehen, und in beiden Fällen kann die Ursache die Disk sein, nicht die CPU. Ein OOM-Kill entfernt den grössten Prozess, in der Regel den Hauptdienst und nicht den lecken Hilfsprozess, und hinterlässt als einzigen Beleg eine Zeile im Kernel-Log.

So wird es angewendet

• Load mit nproc vergleichen, dann die Ursache aufschlüsseln: vmstat 1 zeigt die Spalten r und b sowie den CPU-Leerlauf; b (blockiert) bei leerlaufender CPU bedeutet I/O; top zeigt Prozesse im D-Zustand.
• Bei Verdacht auf einen OOM-Kill dmesg -T oder journalctl -k nach «Out of memory: Killed process» durchsuchen; bei oom_dump_tasks auf dem Standardwert 1 listet das Log zusätzlich jede Task mit ihrem oom_score_adj und ihrer Speichergrösse zu diesem Zeitpunkt auf.
• Den primären Dienst mit OOMScoreAdjust=-500 oder ähnlich in seiner systemd-Unit schützen und Batch-Jobs einen positiven Wert geben; besser: den Batch-Job mit MemoryMax= begrenzen, damit er zuerst innerhalb seiner eigenen Cgroup beendet wird.
• MemAvailable in /proc/meminfo beobachten, nicht «free», da der Page-Cache zurückgewinnbar ist.

Stolpersteine

-1000 auf alles Wichtige zu setzen, verschiebt den Kill lediglich auf das, was übrig bleibt, möglicherweise sshd. overcommit_memory=2 (die Richtlinie «nie überbuchen») verlagert den Fehler auf den Zeitpunkt der Allokation, wo viele Programme mit einem Fehlerrückgabewert schlecht umgehen, und verweigert die grossen Vorsichtsanfragen, die laut Kernel-Dokumentation viele Programme stellen. Ein von D-Zustand-Tasks dominierter Load Average reagiert nicht auf zusätzliche CPUs.

Wenn der primäre Dienst selbst wächst

Auf einem Host mit einem einzigen Zweck ist meist der grösste Prozess derjenige, der leckt, und ein stark negativer oom_score_adj darauf sorgt dafür, dass der Kernel zuerst alles andere beendet, während das Leck weiterläuft. Auch den primären Dienst begrenzen: MemoryMax= in seiner Unit, gesetzt unterhalb des physischen Speichers mit Raum für System und Hilfsprozesse, damit ein Out-of-Memory-Zustand innerhalb der eigenen Cgroup des Dienstes gelöst wird und in einem Neustart endet (Restart=on-failure) statt im Verlust von sshd oder des Monitoring-Agenten. MemoryHigh= etwas unterhalb des Maximums drosselt zuerst und erscheint in den Metriken, was aus einem überraschenden Kill eine Warnung macht. Die negative Anpassung klein halten und -1000 für nichts reservieren, das wachsen kann.