Leistung und Virtualisierung

Ein Dienst erreicht seine cgroup-Speichergrenze

Ein Prozess wird trotz verfügbarem Host-RAM beendet. Vergleiche cgroup-Grenzen, memory.events und Abbruchmeldung vor mehr Dienstspeicher.

Auf dieser Seite
  1. Symptome und Geltungsbereich
  2. Mögliche Ursachen
  3. Sicher prüfen
  4. Nächste Schritte nach Befund
  5. Quellen und Prüfung
  6. Verwandte Probleme

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:0kB

Prü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 Result

Ergebnis 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.max

Ergebnis 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?

Hinweis teilen#

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?

Hinweis teilen#

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.