Linux: Out of memory – Killed process (OOM Killer)

So sieht die Meldung aus

Out of memory: Killed process 2314 (php-fpm8.3) total-vm:812344kB, anon-rss:402112kB, file-rss:0kB, shmem-rss:20480kB, UID:33 pgtables:1240kB oom_score_adj:0

Häufige Ursachen

• Zu viele PHP-FPM-Worker oder Datenbank-Puffer für den vorhandenen RAM.
• Speicherleck in einer Anwendung, die über Stunden wächst.
• Kein oder zu wenig Swap, Lastspitzen werden nicht abgefangen.
• cgroup-Limit (MemoryMax, Docker --memory) erreicht – dann „Memory cgroup out of memory“.
• Einmalige Aufgaben wie Backups, Imports oder Bildverarbeitung brauchen kurzzeitig viel Speicher.

Prüfen

1. OOM-Ereignisse im Kernel-Log finden
   journalctl -k --since '24 hours ago' | grep -iE 'out of memory|oom-kill|Killed process'Kopieren
2. Freien Speicher und Swap anzeigen
   free -h; swapon --showKopieren
3. Prozesse mit dem höchsten Speicherverbrauch anzeigen
   ps -eo pid,user,rss,comm --sort=-rss | head -n 10Kopieren
4. Speichergrenzen des betroffenen Dienstes anzeigen
   systemctl show php8.3-fpm.service -p MemoryMax -p MemoryCurrent -p OOMPolicyKopieren

Lösung

• pm.max_children an den RAM anpassen: verfügbarer Speicher geteilt durch durchschnittliche Worker-Größe.
• Datenbankpuffer begrenzen, z. B. innodb_buffer_pool_size passend zum Rest des Systems.
• Etwas Swap einrichten, damit kurze Spitzen nicht sofort zum Kill führen.
• Kritische Dienste schützen: OOMScoreAdjust=-500 in der Unit, unkritische mit MemoryMax begrenzen.
• Speicherverbrauch über Zeit überwachen, um Lecks früh zu sehen.

Häufige Fragen

Warum wurde die Datenbank beendet, obwohl PHP den Speicher verbraucht hat?

Der OOM Killer wählt nach Größe und oom_score_adj, nicht nach Verursacher. Große Dienste wie MariaDB treffen es deshalb oft zuerst.

Hilft es, den Overcommit abzuschalten?

Selten. Mit vm.overcommit_memory=2 scheitern Anwendungen schon bei der Anforderung. Besser Limits pro Dienst setzen und den Verbrauch an den RAM anpassen.