Der Container startet immer wieder neu. Liegt es an Speichermangel?

Exit-Code 137 allein bestätigt kein OOM. So verbinden Sie Containerzustand, Ereignisse und Speicherlimits bei der Untersuchung wiederkehrender Ausfälle.

Zwei grüne RAM-Module mit schwarzen Chips und goldenen Kontakten auf einer hellen Unterlage
Fotografie: Harrison Broadbent / Unsplash

Eine Anwendung läuft nach einem Ausfall wieder, verschwindet aber bei der Verarbeitung einer weiteren großen Datei erneut. Dieses Verhalten ist ein Anlass, den Speicher zu untersuchen, und noch kein Beweis für einen Mangel. OOM, also out of memory, muss von einem Anwendungsfehler oder einer anderen erzwungenen Beendigung unterschieden werden. Diese Anleitung behandelt Docker Engine unter Linux; die Angaben zu Speichercontroller-Dateien beziehen sich auf cgroup v2.

Erfassen Sie den Zustand, solange der Zusammenhang erkennbar ist

Verwenden Sie docker inspect --format '{{.Id}} {{json .State}}' web und ersetzen Sie web durch den Containernamen. Erfassen Sie OOMKilled, ExitCode, StartedAt und FinishedAt zusammen mit der ID. OOMKilled bezieht sich auf die Zeit seit dem letzten Start und ist kein Archiv aller früheren Abstürze. Speichern Sie die Ausgabe mit dem Beobachtungszeitpunkt und vergleichen Sie sie mit einem konkreten Dienstausfall.

Exit-Code 137 allein beweist kein OOM. Er kann mit SIGKILL zusammenhängen, etwa nach dem manuellen Beenden eines Prozesses oder nach docker kill. Prüfen Sie deshalb auch Bereitstellungen und administrative Eingriffe in der Zeitleiste. Ein Limit nur aufgrund einer Zahl zu erhöhen bedeutet, die Konfiguration ohne bestätigte Ursache zu ändern. Klären Sie zuerst, welchen Lauf des Containers Sie untersuchen.

Verbinden Sie Docker-Ereignisse mit Kernelmeldungen

Suchen Sie in docker events für die betreffende ID nach oom, die und start. Die Optionen --since und --until begrenzen den Zeitraum; geben Sie bei Zeitstempeln eine Zeitzone an. Die Ereignishistorie ist begrenzt. Erfassen Sie wichtige Einträge deshalb fortlaufend. Ein fehlender älterer Eintrag widerlegt ein Ereignis nicht. Vergleichen Sie die Zeiten mit der fehlgeschlagenen Anfrage statt nur mit dem aktuellen Containerzustand.

Auf einem Host mit systemd zeigt journalctl -k die Kernelmeldungen. Standardmäßig wird der aktuelle Systemstart ausgewählt; wählen Sie nach einem Host-Neustart den passenden Systemstart und Zeitraum. Vergleichen Sie bei einem OOM-Eintrag Prozess, Zeitpunkt und angegebenen Kontext mit dem betroffenen Container. Fehlen Aufzeichnungen oder Berechtigungen, lassen Sie die Ursache unbestätigt und ergänzen Sie die Erfassung für den nächsten Vorfall.

Vergleichen Sie Containerlimit und Hostzustand

Docker kann Speicher über --memory begrenzen. Freier RAM auf dem Host bestätigt daher nicht, dass das Containerlimit ausreicht. Vergleichen Sie in dessen richtiger cgroup v2 memory.max und memory.current: das harte Limit und den aktuellen Verbrauch einschließlich untergeordneter Gruppen. In memory.events.local zählt oom_kill Gruppenprozesse, die ein OOM-Killer beendet hat. Allein daraus lässt sich lokaler Speichermangel nicht von systemweitem unterscheiden; prüfen Sie auch die Kernelmeldungen.

Einen aktuellen Überblick liefert docker stats --no-stream web. Unter Linux zieht diese Ausgabe einen Teil des Caches ab. Ihr Wert muss deshalb nicht dem Rohwert des Speichercontrollers entsprechen. Erfassen Sie den Verlauf vor einem Vorfall und kennzeichnen Sie die Metrikquelle. Eine einzelne Stichprobe nach der Wiederherstellung erklärt keine frühere Spitze. Verwenden Sie vor und nach einer Änderung dieselbe Messung.

Prüfen Sie die Reparatur mit der zuvor fehlgeschlagenen Arbeit

Wiederholen Sie in einer getrennten Umgebung die entsprechende Datenmenge und Parallelität. Prüfen Sie, ob kleinere Stapel, weniger parallele Vorgänge oder eine Änderung der Speicherverwaltung helfen. Steigender Verbrauch ist ein Anlass für Profiling und noch kein Beweis für ein Speicherleck. Muss das Limit steigen, bewerten Sie zuerst die Hostkapazität und die übrigen Dienste. Das Abschalten des OOM-Schutzes ersetzt keine Diagnose.

Eine Neustartrichtlinie kann den Container erneut starten, beseitigt aber nicht die Ursache seiner Beendigung. Beobachten Sie nach der Reparatur weitere Abstürze, den Speicherverlauf und das Ergebnis des ursprünglichen Vorgangs. Ergänzen Sie externe Verfügbarkeitsprüfungen um interne Speicher- und Neustartdaten. Bestätigen Sie auch den erfolgreichen Abschluss der Dateiverarbeitung unter vergleichbarer Last. Ein wieder laufender Prozess allein reicht dafür nicht.

  • Erfassen Sie Container-ID, Zustand und Zeitpunkt des betroffenen Laufs.
  • Vergleichen Sie Docker-Ereignisse mit Kernelmeldungen.
  • Prüfen Sie Limit, Verbrauchsverlauf und Hostkapazität.
  • Wiederholen Sie den ursprünglichen Vorgang und beobachten Sie weitere Abstürze.

Was Sie mitnehmen

Verbinden Sie bei wiederkehrenden Neustarts den Nachweis der Prozessbeendigung mit Speichermessungen und dem Ausfallzeitpunkt. Entscheiden Sie erst dann über Änderungen an Anwendung oder Limit. Fehlt die Historie, halten Sie diese Unsicherheit im Ergebnis fest und ergänzen Sie Messungen, die beim nächsten Auftreten eine Prüfung der Ursache ermöglichen.

Dokumentation und weiterführende Links

Mgr. Martin Hlavaj, MBA

Softwareentwickler

Alle Artikel

Erfahren Sie frühzeitig von Ausfällen.

Fügen Sie Ihre Website oder API zu UpBot hinzu und bestimmen Sie, wer den Alarm erhält.

Kostenlos überwachen