Wenn Sie einen Linux-Server verwalten, ist es ein Albtraum, aufzuwachen und festzustellen, dass Ihr kritischer Datenbank- oder Webserver-Prozess unerwartet beendet wurde. Oftmals ist der Schuldige der Out of Memory (OOM) Killer, eine gnadenlose, aber notwendige Komponente des Linux-Kernels. Dieser Leitfaden erklärt, warum der OOM Killer zuschlägt, wie man ein OOM-Ereignis eindeutig diagnostiziert und wie Sie Ihr System konfigurieren können, um zu verhindern, dass er Ihre Infrastruktur lahmlegt.

Was ist der OOM Killer?

Wenn einem Linux-System der physische RAM und der Swap-Speicher vollständig ausgehen, droht ein vollständiges Einfrieren des Systems. Um dies zu verhindern, ruft der Kernel den OOM Killer auf.

Der OOM Killer untersucht alle laufenden Prozesse, berechnet eine “Erschwernis”-Punktzahl (oom_score), die primär auf der Speichernutzung basiert, und beendet dann gewaltsam (SIGKILL) den Prozess mit der höchsten Punktzahl, um sofort Speicher freizugeben und das System zu retten.

Der Fehler: Wie Sie den OOM Killer in Aktion ertappen

Da der OOM Killer auf Kernel-Ebene arbeitet, hat Ihre Anwendung selten Zeit, einen Fehler in ihre eigene Protokolldatei zu schreiben. Stattdessen verschwindet der Prozess einfach.

Um eine OOM-Tötung zu bestätigen, müssen Sie die Kernel-Protokolle überprüfen. Führen Sie aus:

dmesg -T | grep -i "Out of memory"

Oder, um genau zu sehen, welcher Prozess getötet wurde:

dmesg -T | egrep -i "killed process"

Sie werden eine Ausgabe ähnlich dieser sehen:

[Fri Feb 27 10:15:30 2026] Out of memory: Killed process 12345 (mysqld) total-vm:4567890kB, anon-rss:3456780kB, file-rss:0kB, shmem-rss:0kB, UID:111 pgtables:8000kB oom_score_adj:0

Die Ursache: Warum ist es passiert?

Der OOM Killer schlägt nur zu, wenn das System nach Speicher hungert. Häufige Szenarien sind:

  1. Ein Speicherleck (Memory Leak): Eine fehlerhafte Anwendung (oft benutzerdefinierter Code oder speicherverwaltete Sprachen wie Java oder Node.js ohne angemessene Einschränkungen) verbraucht im Laufe der Zeit langsam RAM, bis der Server erschöpft ist.
  2. Plötzliche Verkehrsspitze: Ein Anstieg des Webverkehrs hat zu viele PHP-FPM- oder Apache-Arbeiterprozesse generiert, wodurch der Speicherbedarf exponentiell anstieg.
  3. Falsche Datenbankkonfiguration: Eine Datenbank wie MySQL ist so konfiguriert, dass sie mehr Speicher verbraucht (z.B. innodb_buffer_pool_size), als der Server physisch besitzt.
  4. Kein Swap-Speicher: Der Server hat exakt 0 Bytes Swap konfiguriert, sodass der Kernel kein Sicherheitsnetz hat, wenn der RAM vollläuft.

Lösung Schritt für Schritt

Schritt 1: Auslagerungsspeicher (Swap) hinzufügen oder erhöhen

Wenn Ihr Server keinen Swap-Speicher hat, kann das Hinzufügen einer auch nur geringen Menge plötzliche, temporäre Spitzen in der Speichernutzung auffangen und Ihnen Zeit verschaffen, zu reagieren, bevor der OOM Killer aktiv wird.

Erstellen Sie eine 2GB Auslagerungsdatei:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Machen Sie dies dauerhaft, indem Sie es der /etc/fstab hinzufügen:

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Schritt 2: Anwendungskonfiguration optimieren

Wenn MySQL oder PostgreSQL ständig beendet wird, ist es wahrscheinlich falsch konfiguriert. Überprüfen Sie Ihre Datenbankkonfiguration (z.B. /etc/mysql/my.cnf) und stellen Sie sicher, dass die Puffer für Ihre Hardware angemessen dimensioniert sind. Eine gängige Regel für die innodb_buffer_pool_size ist 50-70% des gesamten RAMs, aber wenn Sie einen Webserver auf derselben Maschine betreiben, muss dieser Wert deutlich niedriger sein.

Für PHP/Apache/Nginx: Reduzieren Sie die maximale Anzahl der Arbeiter- (Worker-) oder untergeordneten Prozesse, die gleichzeitig erstellt werden dürfen.

Schritt 3: Den OOM-Wert anpassen (Schutz kritischer Prozesse)

Jeder Prozess hat einen oom_score_adj-Wert, der von -1000 bis 1000 reicht. Je höher die Zahl, desto wahrscheinlicher wird der OOM Killer ihn ins Visier nehmen. Ein Wert von -1000 macht den Prozess immun.

Wenn Sie einen kritischen Prozess haben (wie sshd, damit Sie sich immer anmelden können, oder einen zentralen Daemon), den Sie absolut nicht verlieren dürfen, können Sie dessen Punktzahl anpassen.

Finden Sie zuerst die PID des Prozesses heraus (z.B. PID 1234).

echo -500 > /proc/1234/oom_score_adj

(Sie benötigen ein Skript, um dies bei einem Neustart des Prozesses automatisch auszuführen, oder verwenden Sie systemd).

Die Verwendung von Systemd (Der bessere Weg): Wenn der Prozess von systemd verwaltet wird, können Sie die OOM-Bewertung nativ konfigurieren. Bearbeiten Sie die Service-Datei (z.B. sudo systemctl edit sshd):

[Service]
OOMScoreAdjust=-1000

Führen Sie dann sudo systemctl daemon-reload aus und starten Sie den Dienst neu.

Schritt 4: Überbelegung des Kernels (Kernel Overcommit) verhindern

Standardmäßig erlaubt Linux Anwendungen, mehr Speicher anzufordern, als das System tatsächlich besitzt (Memory Overcommit). Es geht davon aus, dass nicht alle Anwendungen das, was sie anfordern, auch nutzen werden. Wenn sie es dann doch tun, erhalten Sie ein OOM-Ereignis.

Sie können dieses Verhalten via sysctl einschränken:

sudo sysctl -w vm.overcommit_memory=2
sudo sysctl -w vm.overcommit_ratio=80

Dies weist den Kernel an, keine Speicherzuweisung zuzulassen, die (Swap + 80% des RAMs) übersteigt. Fügen Sie dies zu /etc/sysctl.conf hinzu, um es über Neustarts hinweg beizubehalten.

Prävention

Um den OOM-Killer dauerhaft in Schach zu halten:

  • Überwachung (Alerting) implementieren: Richten Sie Prometheus, Datadog oder einfache Monit-Skripte ein, die Sie alarmieren, wenn die Speichernutzung 85% übersteigt.
  • Cgroups einrichten: Wenn Sie Docker oder Kubernetes ausführen, legen Sie strenge Speichergrenzen für Container fest (--memory="512m"). Wenn ein Prozess innerhalb des Containers durchdreht, tötet der OOM Killer nur den Container, während das Host-System völlig unbeschadet bleibt.
  • Die Servergröße anpassen: Manchmal gibt es keine Softwarelösung für einen Mangel an Hardware. Wenn Ihre Basis-Anwendung berechtigterweise 8 GB RAM für eine effiziente Ausführung benötigt und Sie einen 4 GB VPS haben, müssen Sie ein Upgrade durchführen.

Zusammenfassung

  • Der Linux OOM Killer ist ein Kernel-Verteidigungsmechanismus, der den speicherintensivsten Prozess tötet, um ein hungerndes System vor dem Einfrieren zu bewahren.
  • Die Diagnose eines OOM-Ereignisses erfordert die Überprüfung des Kernel-Ringpuffers mithilfe von dmesg.
  • Verhindern Sie OOM-Tötungen, indem Sie Swap-Speicher konfigurieren, die Speicherlimits von Anwendungen anpassen (wie MySQL-Puffergrößen) und strikte Limits über cgroups oder systemd festlegen.
  • Sie können wichtige Daemons schützen, indem Sie ihren Wert OOMScoreAdjust direkt nativ über systemd senken.

Verwandte Artikel