Symptome und Geltungsbereich
- Eine Kernelmeldung nennt Memory cgroup out of memory.
- Der Dienst scheitert mit oom-kill, während andere Anwendungen aktiv bleiben.
Betroffene Umgebung
Linux-cgroup-v2-Memory-Controller; systemd-MemoryHigh, MemoryMax und Eltern-Slices.
Erkennbare Meldungen (synthetische Beispiele)
kernel: Memory cgroup out of memory: Killed process 932 (example) total-vm:3000000kB, anon-rss:1900000kB, file-rss:0kBPrüfe lokale und Elternlimits samt umgebenden OOM-Einschränkungen.
systemd[1]: example.service: Failed with result 'oom-kill'.Dies meldet eine OOM-bezogene Beendigung, nicht zwingend eine lokale MemoryMax-Verletzung.
Mögliche Ursachen
Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.
- Die cgroup oder ihr Elternbereich kann memory.max erreichen und zu wenig für eine Allokation zurückgewinnen.
- Zu hohe Parallelität oder wachsender Cache kann eine ansonsten beabsichtigte Speichergrenze überschreiten.
Sicher prüfen
Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.
Prüfschritt 1
Ersetze die Unit; liest Regel und Fehlerergebnis ohne Neustart.
systemctl show example.service -p ControlGroup -p MemoryHigh -p MemoryMax -p MemorySwapMax -p ResultErgebnis einordnen: MemoryHigh erzeugt Druck und Reclaim; MemoryMax ist eine harte Grenze. Elternlimits können lokale Werte überwiegen.
Prüfschritt 2
Nutze ControlGroup unter /sys/fs/cgroup; benötigt cgroup v2 und eine noch vorhandene cgroup.
cat /sys/fs/cgroup/system.slice/example.service/memory.events /sys/fs/cgroup/system.slice/example.service/memory.current /sys/fs/cgroup/system.slice/example.service/memory.maxErgebnis einordnen: Vergleiche max-/oom-Ereignisse mit der Abbruchmeldung. oom_kill zählt Mitglieder aller OOM-Arten; der Zähler allein beweist kein lokales Limit.
Nächste Schritte nach Befund
Bestätigte Speichergrenze passend wählen
Wenn berechtigte Spitzen eine versehentlich niedrige Grenze übersteigen, erhöhe endliches MemoryMax dieses Dienstes und prüfe MemoryHigh sowie Elternbudget. Prüfe Hostreserve und dieselbe Last.
Vorsicht: Mehr Einzelbudget kann OOM-Druck auf den Host verlagern. Ein Kindlimit überschreibt sein Elternlimit nicht.
Wiederherstellung / Rücknahme: Stelle Budgets zurück und starte Arbeit nach ihrem unterstützten Rückweg; ungesicherter Zustand eines beendeten Prozesses kommt nicht zurück.
Hat dir dieser Hinweis geholfen?
Budget behalten und Bedarf senken
Wenn Isolation beabsichtigt ist, reduziere Worker, Batchgröße oder Cache für das Budget und untersuche Speicherlecks. Nutze unterstützte Wiederaufnahme oder Checkpoints.
Vorsicht: Deaktiviere keinen OOM-Schutz und setze nicht alle Dienste unbegrenzt. Die Abbruchmeldung identifiziert nicht die verursachende Allokation.
Wiederherstellung / Rücknahme: Stelle frühere Anwendungsgrößen nur bei passendem Budget zurück; nutze gültige Checkpoints oder Sicherungen.
Hat dir dieser Hinweis geholfen?
Quellen und Prüfung
Diese Anleitung basiert auf Originalquellen von Projekten oder Distributionen und wurde am genannten Datum redaktionell geprüft. Das ist eine Quellenprüfung, kein Nachweis einer auf deiner Hardware reproduzierten Lösung. Log-Beispiele sind synthetische Testdaten. Versionsabhängige Details müssen zur installierten Ausgabe passen.
- Linux kernel — cgroup v2 controllers (Projekt- oder Distributionsdokumentation)
- systemd resource control — upstream manual hosted by Debian (Projekt- oder Distributionsdokumentation)
- Linux kernel — OOM kill implementation (Upstream-Implementierung; Verhalten ist versionsabhängig)