Was verursacht es, dass ein Container die Systemfestplatte füllt, obwohl seine Daten anderswo gespeichert sind?

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

What Causes a Container to Fill the System Disk When Its Data Is Elsewhere? - Zima Store Online

Ein Container kann die Systemfestplatte füllen, wenn Protokolle, Caches, temporäre Dateien oder versehentliche Schreibvorgänge im lokalen Docker-Speicher verbleiben.

Das Verschieben einer Medienbibliothek oder eines Datenbank-Volumes in einen anderen Pool verschiebt nicht das Container-Image, die beschreibbare Ebene, das JSON-Protokoll, den BuildKit-Cache, Metadaten oder Pfade, die in der Mount-Liste fehlen. Ein fehlgeschlagener externer Mount kann außerdem dazu führen, dass das erwartete Host-Verzeichnis leer bleibt. Dadurch schreibt die Anwendung neue Daten auf die Systemfestplatte, ohne einen offensichtlichen Fehler zu melden.

Docker-Root messen, bevor Anwendungsdaten untersucht werden

Prüfen Sie das Dateisystem, das den Docker-Datenstamm enthält, und vergleichen Sie die Größen der Host-Verzeichnisse mit der von Docker erfassten Belegung durch Images, Container, Volumes und den Build-Cache. Erfassen Sie die Nutzung, bevor Sie etwas löschen.

Ein Cloudron-Benutzer stellte fest, dass /var/lib/docker/overlay2 mehr Speicher belegte als alle sichtbaren Anwendungsdaten zusammen. Das zeigt, warum der Docker-Speicherstamm unabhängig von externen Bibliotheken gemessen werden muss.

Wenn die Systemfestplatte voll ist, der externe Pool aber noch freien Speicher hat, ermitteln Sie, ob das Wachstum auf Container, Overlay-Ebenen, Volumes, Images oder den Build-Cache entfällt. Führen Sie kein umfassendes Prune aus, bevor aktive und wiederherstellbare Daten klassifiziert wurden.

Unbegrenzte JSON-Containerprotokolle prüfen

Untersuchen Sie den Protokolltreiber und die Größe der Protokolldatei jedes Containers. Ein Dienst kann seine primären Daten an einem anderen Ort speichern, während stdout und stderr im lokalen Container-Verzeichnis von Docker unbegrenzt anwachsen.

Code Maven dokumentiert einen Fall, in dem docker system df das Hauptproblem nicht sichtbar machte, weil die standardmäßige Protokolldatei außerhalb dieser Zusammenfassung weiter anwuchs. Der verborgene Speicherverbraucher war ein unaufhörlich wachsendes Containerprotokoll.

Finden und beheben Sie den lauten Anwendungsfehler, bevor Sie Protokolle rotieren oder kürzen. Konfigurieren Sie für zukünftige Container eine begrenzte Protokollrotation und prüfen Sie, ob die neuen Dateien beim erwarteten Limit nicht weiter anwachsen.

Daten in der beschreibbaren Container-Ebene finden

Vergleichen Sie die vorgesehenen persistenten Pfade mit den tatsächlichen Cache-, Transkodierungs-, Download-, Datenbank-, Thumbnail-, Backup- und temporären Verzeichnissen der Anwendung. Jeder nicht gemountete Schreibvorgang verbleibt in der beschreibbaren Ebene des Containers auf der Systemfestplatte.

Eine Erklärung in einem Docker-Forum weist darauf hin, dass Schreibvorgänge und geänderte Image-Dateien in der beschreibbaren Ebene gespeichert werden, während große, nicht rotierte Protokolle in den Container-Metadaten liegen. Beides kann dazu führen, dass ein einzelner Container trotz eines externen Daten-Volumes nahezu den gesamten lokalen Speicher belegt.

Verwenden Sie die Größenberichte pro Container und untersuchen Sie die größten geänderten Pfade innerhalb des Containers. Fügen Sie nur für Daten, die dauerhaft gespeichert werden müssen, explizite Bind-Mounts oder benannte Volumes hinzu. Erstellen Sie den Container anschließend neu, um veraltete Inhalte der beschreibbaren Ebene zu verwerfen, nachdem Sie alle wertvollen Daten gesichert haben.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Prüfen, ob der externe Mount beim Start des Containers vorhanden war

Prüfen Sie, ob die SSD, die NAS-Freigabe oder der Speicherpool am erwarteten Host-Pfad gemountet war, bevor Docker den Container gestartet hat. Vergleichen Sie die Geräteidentität und die Mount-Ausgabe mit dem Verzeichnis, das der Container sieht.

Wenn ein externer Mount fehlt, kann das zugrunde liegende leere Verzeichnis auf dem Systemdateisystem weiterhin vorhanden sein. Der Container kann normal in dieses Ausweichverzeichnis schreiben, wodurch die Systemfestplatte wächst, während der externe Pool scheinbar unverändert bleibt.

Stoppen Sie den Container, bevor Sie den Speicher über die bereits gefüllten Ausweichdaten mounten. Verschieben oder gleichen Sie die verborgenen Dateien sicher ab, fügen Sie Mount-Abhängigkeiten oder Startprüfungen hinzu und verhindern Sie den Anwendungsstart, wenn das erwartete Gerät fehlt.

Image-Ebenen, Build-Cache und verwaiste Objekte untersuchen

Überprüfen Sie ungenutzte Images, gestoppte Container, anonyme Volumes und den BuildKit-Cache. Häufige Aktualisierungen oder lokale Builds können viele Ebenen ansammeln, selbst wenn die persistenten Anwendungsdaten korrekt an anderer Stelle gemountet sind.

Eine Erklärung im Moby-Projektforum stellt klar, dass Overlay-Mounts die Ermittlung des Speicherverbrauchs erschweren können und dass die Nutzung des zugrunde liegenden Dateisystems sorgfältig interpretiert werden muss. Ein separater Home-Assistant-Fall zeigte außerdem im Laufe der Zeit ein Wachstum von overlay2 durch Protokolle und Ebenen.

Entfernen Sie nur Objekte, die von den aktuellen Compose-Projekten und Backups eindeutig als ungenutzt bestätigt wurden. Löschen Sie niemals einzelne overlay2-Verzeichnisse manuell, da dadurch die Verweise in Dockers Metadaten inkonsistent werden können.

Die Behebung mit einer Wachstums-Baseline überprüfen

Erfassen Sie nach der Korrektur des verantwortlichen Pfads in regelmäßigen Abständen die Nutzung des Docker-Roots, die Protokollgrößen, die beschreibbaren Container-Größen und die Nutzung des externen Pools, während die Arbeitslast ausgeführt wird, die zuvor das Wachstum verursacht hat.

Der ZimaSpace-Workflow zum Vorbereiten einer großen NAS-Übertragung bietet eine reproduzierbare Belastung, um zu bestätigen, dass Daten im vorgesehenen Pool landen.

Das Problem ist erst dann behoben, wenn das Wachstum der Systemfestplatte dem erwarteten Verhalten von Images und Protokollen entspricht, persistente Anwendungsdaten auf dem externen Pool wachsen und ein fehlender externer Mount einen sicheren Startfehler verursacht, anstatt stillschweigend Schreibvorgänge im Root-Dateisystem auszuführen.