OOM-Killer Out-of-memory killer

Ursachen-ID so-oom · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)

In der interaktiven Fassung mit Grafiken und Experimenten öffnen →

Geht der Arbeitsspeicher aus, wählt Linux den Prozess mit dem größten Speicherverbrauch und beendet ihn zwangsweise. Meist trifft es den Spielserver.

Warum Speicher durch ein Leck oder einen sprunghaften Anstieg erschöpft, oder Speicherlimit des Containers erreicht → Folge Kernel beendet den Spielserver-Prozess zwangsweise → Auf dem Bildschirm Verbindungsabbruch für alle auf diesem Server gleichzeitig, der jüngste Spielfortschritt geht per Rollback möglicherweise verloren

Symptome: Verbindungsabbruch, Verschluckte Aktion / Rollback
Faktoren: Stillstand
Wer ist betroffen: Ganzer Server
Wann: Je länger es läuft, Bei großem Andrang
Zuständigkeit: Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Aufgaben Entwicklungsteam: Leck beheben, Obergrenze für den Speicherverbrauch festlegen und bei Annäherung speichern und geordnet herunterfahren.
Aufgaben Infrastrukturteam: Speicheralarme einrichten, Speicherlimit des Containers an den tatsächlichen Verbrauch anpassen, steuern, welcher Prozess zuerst beendet wird (oom_score_adj).
Größenordnungen: Im Kernel-Log (dmesg) steht „Out of memory: Killed process“, in Kubernetes erscheint der Status OOMKilled. Windows hat keinen OOM-Killer. Dort scheitert eine Speicherzuweisung, und der Server stürzt häufig mit einem Fehler ab.
Im Graphen: Verbindungen brechen gleichzeitig ab · Verbindungen, Speicherverbrauch
Wo nachsehen: Eintrag „Out of memory: Killed process“ in dmesg, bei Kubernetes OOMKilled im Pod-Status, bei cgroup v2 den Zuwachs von oom_kill in memory.events mit dem Zeitpunkt der Verbindungsabbrüche abgleichen
Spricht dafür: Zum Zeitpunkt der gleichzeitigen Verbindungsabbrüche ist das Beenden des Spielserver-Prozesses protokolliert, kurz davor stieg der Speicherverbrauch bis zum Limit
Spricht dagegen: Kein OOM-Eintrag, Prozess trotzdem beendet: Absturzlog und Core-Dump wie unter „Serverabsturz“ beschrieben prüfen
Prüfmittel: Mit Infrastruktur-Tools prüfbar (ohne Spielcode)

Quellen

mm/oom_kill.c (Linux v6.12) Linux kernel
Der Prozess mit dem größten Speicherverbrauch erhält die höchste Punktzahl (unter Berücksichtigung von oom_score_adj), beim Beenden wird „Out of memory: Killed process …“ protokolliert
Assign Memory Resources to Containers and Pods Kubernetes
Überschreitet ein Container dauerhaft sein Speicherlimit (limit), wird er beendet und mit dem Status OOMKilled angezeigt
Pushing the Limits of Windows: Virtual Memory Microsoft
Unter Windows scheitern bei erreichtem Commit-Limit Zuweisungen, die Speicher fest zusagen (committen), das kann zu Anwendungsfehlern oder Systemstörungen führen
Control Group v2 Linux kernel
oom_kill in memory.events: Zahl der Prozesse, die der OOM-Killer in dieser cgroup beendet hat

OOM-Killer Out-of-memory killer

Quellen

Verwandte Ursachen

Gleiche Schicht: L7 Server-OS (Kernel)

Ursachen aus anderen Schichten mit demselben Symptom (Verbindungsabbruch)