Warum behält ein laufender Container sein altes Speicherlimit bei, nachdem die Compose-Datei geändert wurde?
Ein laufender Container behält sein altes Speicherlimit bei, wenn die bearbeitete Compose-Konfiguration nie auf die Live-cgroup dieses Containers angewendet wurde.
Das Ändern der YAML-Datei verändert einen bestehenden Container nicht automatisch, und ein gewöhnlicher Neustart startet denselben Container mit derselben Konfiguration zum Erstellungszeitpunkt. Verwirrung entsteht außerdem durch den Vergleich eines harten Speicherlimits mit einer Reservierung, einer Swap-Zuweisung, dem übergeordneten systemd-Scope oder einer Heap-Einstellung der Anwendung. Ermitteln Sie den effektiven cgroup-Wert und die Container-ID, bevor Sie zu dem Schluss kommen, dass Docker die Änderung ignoriert hat.
Lesen Sie das Live-cgroup-Limit statt der YAML-Datei zu vertrauen
Notieren Sie die Container-ID, die Erstellungszeit, die Docker-Inspektionsausgabe, die cgroup-Version und die Speichersteuerungsdateien, die vom laufenden Prozess verwendet werden.
Der Linux-Kernel definiert memory.max als hartes cgroup-Limit, während memory.high Reclaim-Druck ausübt, ohne dieselbe absolute Obergrenze darzustellen.
Wenn die Live-cgroup weiterhin den alten Wert enthält, wurde die Konfiguration nicht angewendet. Enthält sie den neuen Wert, stimmen die Monitoring-Daten aber nicht überein, prüfen Sie Einheiten, Cache-Abrechnung, Swap und Metriken auf Anwendungsebene.
Unterscheiden Sie zwischen Neustart und Neuerstellung des Containers
Vergleichen Sie die Container-ID vor und nach dem Befehl, mit dem Sie die Änderung bereitgestellt haben. Notieren Sie, ob der Befehl restart, up, create, eine NAS-UI-Aktion oder ein direktes Docker-Update war.
Docker erklärt, dass Compose restart keine Konfigurationsänderungen übernimmt, da die vorhandenen Service-Container neu gestartet werden.
Verwenden Sie ein kontrolliertes Compose-Update, das den Service neu erstellt, oder bei Bedarf ein unterstütztes Live-Update der Ressourcen. Bewahren Sie die alte Inspektionsausgabe auf, damit das geänderte Feld überprüft werden kann.
Validieren Sie das endgültige Compose-Modell und das Speicherfeld
Rendern Sie die effektive Compose-Konfiguration, nachdem alle Dateien, Profile und Umgebungsvariablen-Ersetzungen angewendet wurden. Prüfen Sie, ob das Limit zum aktiven Service gehört.
Die Compose-Spezifikation definiert mem_limit als Speicherlimit eines Service und verlangt Konsistenz, wenn gleichwertige deploy-Limits ebenfalls angegeben sind.
Ein Wert in einer nicht verwendeten Override-Datei, einem inaktiven Profil, einem falsch geschriebenen Service oder einer anderen Stack-UI ändert das bereitgestellte Modell nicht. Vergleichen Sie die gerenderte Konfiguration mit der Docker-Inspektion.
Trennen Sie hartes Limit, Reservierung und Swap
Notieren Sie das harte Speicherlimit, die Reservierung beziehungsweise das Soft-Limit, das Swap-Limit, die aktuelle Nutzung, die Spitzennutzung und OOM-Ereignisse. Behandeln Sie nicht jeden speicherbezogenen Wert als dieselbe Obergrenze.
Die Dokumentation zur Ressourcensteuerung von systemd unterscheidet MemoryHigh von MemoryMax und zeigt, dass übergeordnete cgroups zusätzliche Limits für Services und Container festlegen können.
Ein Container kann eine Reservierung scheinbar überschreiten, weil eine Reservierung nicht dasselbe wie ein hartes Limit ist. Er kann außerdem Swap oder Seiten-Cache verwenden, den ein Dashboard nicht berücksichtigt oder separat meldet.
Prüfen Sie, ob der Runtime-Heap eine eigene Obergrenze verwendet
Bei Java-Anwendungen sollten Sie die containerbewusste JVM-Erkennung, die maximale Heap-Größe, den Direct Memory, den Metaspace, die Thread-Stacks und die vom Image oder der Anwendungskonfiguration übergebenen Flags erfassen.
Oracle dokumentiert, dass die JVM ihren Heap anhand verfügbarer Speicherbeschränkungen dimensioniert und mit MaxRAMPercentage den Heap-Anteil festlegen kann.
Das Ändern des Containerlimits führt möglicherweise nicht zur erwarteten Heap-Größe der Anwendung, wenn weiterhin ein explizites -Xmx oder ein Prozentsatz festgelegt ist. Der Heap-Speicher entspricht außerdem nicht dem gesamten Speicherverbrauch des Prozesses.
Prüfen Sie Node.js- und andere Limits auf Anwendungsebene
Überprüfen Sie Runtime-Flags, Umgebungsvariablen, die Anzahl der Worker, Caches und interne Speicherziele. Vergleichen Sie diese mit dem Limit des Betriebssystems.
Node.js dokumentiert max-old-space-size als V8-Heap-Limit, das unverändert bleiben kann, selbst nachdem der Container eine größere oder kleinere cgroup-Zuweisung erhalten hat.
Ein Containerlimit schützt den Host; es stimmt nicht automatisch jede Anwendung ab. Legen Sie die Runtime unterhalb der Containerobergrenze fest und lassen Sie Raum für native Speicherzuweisungen und Dateisystem-Cache.
Wenden Sie eine Änderung an und überprüfen Sie sie unter kontrollierter Last
Rendern Sie das endgültige Compose-Modell, erstellen Sie nur den betroffenen Service neu, bestätigen Sie die neue Container-ID und die Live-cgroup und führen Sie anschließend eine begrenzte Arbeitslast aus, während Sie Nutzung und OOM-Ereignisse beobachten.
Der Artikel „Was passiert, wenn ein Home-Server-Container sein Speicherlimit erreicht?“ im ZimaSpace Tech & AI Hub erklärt, was bei einem aktiven Containerlimit geschieht; dieser Artikel konzentriert sich darauf nachzuweisen, dass ein geändertes Limit tatsächlich bereitgestellt wurde.
Das Problem ist behoben, wenn gerenderte Konfiguration, Container-Inspektion, cgroup-Dateien, Runtime-Heap und beobachtete Fehlergrenze nach einem Neustart alle mit der vorgesehenen Richtlinie übereinstimmen.
Häufig gestellte Fragen
Wird ein geändertes Compose-Speicherlimit durch einen Neustart des Containers übernommen?
Nein. Ein Neustart verwendet normalerweise weiterhin die Konfiguration des vorhandenen Containers. Erstellen Sie den Service neu oder verwenden Sie ein unterstütztes Live-Update.
Kann ein Container sein hartes Speicherlimit vorübergehend überschreiten?
Kernel-Abrechnung und Reclaim können kurzfristig Werte nahe an oder geringfügig über einer Grenze anzeigen, aber anhaltende, nicht zurückforderbare Nutzung am harten Limit führt zur cgroup-OOM-Behandlung.
Warum meldet die Anwendung weiterhin die alte Heap-Größe?
Die Runtime der Anwendung kann ein explizites Heap-Flag verwenden oder einen Prozentsatz nur beim Start berechnen. Erstellen Sie den Container neu oder starten Sie ihn neu, nachdem Sie das Containerlimit validiert haben.
Empfohlene Produkte
Support & Tipps
Mehr zum Lesen
Warum stellt eine Docker-Volume-Wiederherstellung zwar die Dateiinhalte wieder her, lässt aber erweiterte Attribute weg?
Eine Diagnose zur Wiederherstellung von Volumes mit einer Bestandsaufnahme der erweiterten Attribute, Tar- und Rsync-Optionen, Namespaces, Zielunterstützung, Berechtigungen, Labels, App-Metadaten und Tests.
Warum macht ein Neustart des Reverse-Proxys jede Sitzung für eine selbst gehostete App ungültig?
Eine Diagnose von Sitzungsverlusten mit Abdeckung des Neustartumfangs, der Cookie-Zuständigkeit, der Geheimnisrotation, cachebasierten Sitzungen, Sticky-Routing, Authentifizierungs-Gateways und der Wiederherstellung.
Warum wird ein Compose-Netzwerkalias nach der Neuerstellung des Stacks unter einem neuen Projektnamen nicht mehr aufgelöst?
Eine Compose-DNS-Diagnose zu Projektnamen, netzwerkbezogenen Aliasen, externen Netzwerken, integriertem DNS, der Proxy-Anbindung, veralteten Endpunkten und der Neuerstellung.
