# OOM Killer Advanced: Vom automatischen Tod zur kontrollierten Reaktion

TL;DR / Management Summary In einem einfachen System ist der OOM-Killer (Artikel 376) ein Retter. In einem HA-Cluster (High Availability) hingegen kann er zum Problem werden: Ein Server, der wichtige Dienste killt, hinkt oft nur noch “halb-tot” vor sich hin. Ein Senior Admin konfiguriert in solchen Fällen Panic-on-OOM, um einen harten Failover des gesamten Nodes zu erzwingen, oder nutzt systemd-oomd, um proaktiv im User-Space einzugreifen, bevor der Kernel-Killer zuschlägt.

# 1. Einführung & Architektur

Die Mathematik des Todes.

Der Kernel berechnet den oom_score (Badness Score) nach einer festen Formel: $$Badness = \frac{RSS}{Total RAM} \times 1000 + oom_score_adj$$

• Prozesse mit vielen Kind-Prozessen (wie Apache) werden bevorzugt gekillt, da sie viel Speicher auf einmal freigeben.
• Root-Prozesse erhalten einen Bonus und sterben später.

# Die Eskalations-Optionen (Mermaid)

graph TD
    A[Out of Memory Condition] --> B{Panic on OOM enabled?}
    B -->|Yes| C[Kernel Panic: Immediate Reboot]
    B -->|No| D{systemd-oomd active?}
    D -->|Yes| E[Proactive Kill based on PSI]
    D -->|No| F[Kernel OOM Killer: Select Victim]
    C --> G[HA Cluster: Failover to Node B]
    E --> H[Graceful Service Restart]
    F --> I[Random Process Death]

# 2. Panic on OOM: Die Cluster-Strategie

Lieber tot als krank.

In einem Pacemaker-Cluster (Artikel 055) ist es oft besser, wenn der Node komplett neu startet, anstatt dass der OOM-Killer wichtige Datenbank-Threads beendet.

# Aktivierung

# Rebootet den Server nach 10 Sekunden bei OOM
sudo sysctl -w kernel.panic_on_oops=1
sudo sysctl -w vm.panic_on_oom=1
sudo sysctl -w kernel.panic=10

# 3. systemd-oomd: Der User-Space Wächter

Proaktives Handeln.

Modernes Linux (SLES 15, Arch, Fedora) nutzt oft systemd-oomd. Er schaut auf den Ressourcen-Druck (PSI) (Artikel 216) statt nur auf den freien RAM.

# Konfiguration

Datei: /etc/systemd/oomd.conf

[OOM]
# Killt die gesamte Cgroup (Slice), wenn der Druck > 20% für 10s ist
DefaultMemoryPressureLimit=20%
DefaultMemoryPressureDurationSec=10s

# 4. Day-2 Operations: OOM-Events überwachen

Keine lautlosen Exits.

# OOM Nachrichten abfangen

Stellen Sie sicher, dass Ihre Monitoring-Agents nach dem String Out of memory in dmesg suchen.

# Suche nach historischen OOM Ereignissen
ausearch -m ANOM_ABEND -i

# 5. Troubleshooting & “War Stories”

Wenn der Falsche stirbt.

# Story 1: “Der hängende SSH-Dämon”

Symptom: Der Server ist per SSH nicht mehr erreichbar, obwohl die Webseite noch läuft. Ursache: Der OOM-Killer hat sshd ausgewählt, weil dieser beim Login kurzzeitig viel Speicher reservierte. Lösung: Schützen Sie systemkritische Dämons via systemd Unit-File: OOMScoreAdjust=-1000.

# Story 2: “Der Memory-Limit Trugschluss”

Symptom: Eine VM auf Proxmox stürzt ständig ab, obwohl laut free im Gast noch 50% RAM frei sind. Ursache: Der Host (Proxmox) hat ein Limit für den QEMU-Prozess gesetzt. Der OOM-Killer wird auf dem Host aktiv und beendet die gesamte VM, ohne dass der Gast jemals eine Warnung erhalten hat. Lösung: Passen Sie die RAM-Reservierung in Proxmox an und aktivieren Sie den VirtIO Memballoon Treiber, damit Host und Gast miteinander über den Speicherdruck kommunizieren können.

# 6. Fazit & Empfehlung

• HA-Cluster: Nutzen Sie vm.panic_on_oom=1.
• Desktop/Workstation: Nutzen Sie systemd-oomd für flüssigeres Arbeiten.
• Wahl: Verlassen Sie sich niemals darauf, dass der OOM-Killer “das Richtige” tut. Er ist eine Notfallmaßnahme, keine Ressourcenplanung.

# Anhang: Cheatsheet