Vad får en container att fylla systemdisken när dess data finns någon annanstans?
En container kan fylla systemdisken när loggar, cachefiler, temporära filer eller oavsiktliga skrivningar blir kvar i Dockers lokala lagring.
Att flytta ett mediebibliotek eller en databasvolym till en annan lagringspool flyttar inte containeravbildningen, det skrivbara lagret, JSON-loggen, BuildKit-cachen, metadata eller någon sökväg som utelämnats från monteringslistan. En misslyckad extern montering kan också lämna den förväntade värdkatalogen tom, vilket får programmet att skriva nya data till systemdisken utan något tydligt fel.
Mät Dockers rotkatalog innan du granskar programdata
Kontrollera filsystemet som innehåller Dockers datarot och jämför storleken på värdkatalogerna med Dockers redovisning av avbildningar, containrar, volymer och byggcache. Dokumentera användningen innan du tar bort något.
En Cloudron-användare upptäckte att /var/lib/docker/overlay2 använde mer utrymme än all synlig programdata, vilket visar varför Dockers lagringsrot måste mätas separat från externa bibliotek.
Om systemdisken är full men den externa poolen har ledigt utrymme ska du fastställa om tillväxten finns under containrar, overlay-lager, volymer, avbildningar eller byggcache. Kör inte en generell rensning innan aktiva och återställningsbara data har klassificerats.
Kontrollera om containrarnas JSON-loggar växer utan gräns
Kontrollera loggdrivrutinen och storleken på varje containerloggfil. En tjänst kan lagra sina primära data någon annanstans medan stdout och stderr växer obegränsat i Dockers lokala containerkatalog.
Code Maven dokumenterar ett fall där docker system df inte avslöjade huvudproblemet, eftersom standardloggfilen fortsatte att växa utanför den sammanställningen. Den dolda utrymmesförbrukaren var en containerlogg som växte utan stopp.
Hitta och åtgärda det fel i programmet som orsakar överdriven loggning innan du roterar eller trunkerar loggarna. Konfigurera begränsad loggrotation för framtida containrar och kontrollera att de nya filerna slutar växa vid den förväntade gränsen.
Hitta data som skrivs till containerns skrivbara lager
Jämför de avsedda beständiga sökvägarna med programmets faktiska kataloger för cache, omkodning, nedladdningar, databaser, miniatyrbilder, säkerhetskopior och temporära filer. Alla skrivningar till omonterade sökvägar blir kvar i containerns skrivbara lager på systemdisken.
En förklaring på ett Docker-forum påpekar att skrivningar och ändrade avbildningsfiler lagras i det skrivbara lagret, medan stora loggar utan rotation finns i containerns metadata. Båda kan få en enda container att förbruka nästan allt lokalt utrymme trots en extern datavolym.
Använd storleksrapportering per container och granska de största ändrade sökvägarna inuti containern. Lägg till uttryckliga bind-monteringar eller namngivna volymer endast för data som måste bevaras och återskapa sedan containern för att ta bort föråldrat innehåll i det skrivbara lagret, efter att du har säkerhetskopierat allt värdefullt.
Verifiera att den externa monteringen fanns när containern startade
Kontrollera att SSD:n, NAS-resursen eller lagringspoolen var monterad på den förväntade värdsökvägen innan Docker startade containern. Jämför enhetsidentiteten och monteringsinformationen med katalogen som containern ser.
När en extern montering saknas kan den underliggande tomma katalogen på systemfilsystemet ändå finnas kvar. Containern kan skriva normalt till denna reservkatalog, vilket får systemdisken att växa medan den externa poolen verkar orörd.
Stoppa containern innan du monterar lagringen på nytt över data som fyllt reservkatalogen. Flytta eller sammanför de dolda filerna på ett säkert sätt, lägg till monteringsberoenden eller startkontroller och vägra starta programmet när den förväntade enheten saknas.
Granska avbildningslager, byggcache och övergivna objekt
Granska oanvända avbildningar, stoppade containrar, anonyma volymer och BuildKit-cache. Täta uppdateringar eller lokala byggen kan samla på sig många lager även när programmets beständiga data är korrekt monterade någon annanstans.
En förklaring på ett forum för Moby-projektet klargör att overlay-monteringar kan göra diskutrymmets siffror svårtolkade och att användningen i det underliggande filsystemet måste tolkas noggrant. Ett separat Home Assistant-fall visade också tillväxt i overlay2 från loggar och lager över tid.
Ta endast bort objekt som bekräftats vara oanvända av aktuella Compose-projekt och säkerhetskopior. Ta aldrig bort enskilda overlay2-kataloger manuellt, eftersom Dockers metadatareferenser då kan bli inkonsekventa.
Bekräfta åtgärden med en tillväxtbaslinje
Efter att du har korrigerat den ansvariga sökvägen ska du regelbundet dokumentera användningen av Dockers rotkatalog, loggstorlekar, containrarnas skrivbara storlek och den externa poolens användning under den arbetsbelastning som tidigare orsakade tillväxten.
ZimaSpaces arbetsflöde för att förbereda en stor NAS-överföring ger en repeterbar belastning för att bekräfta att data hamnar på den avsedda poolen.
Problemet är åtgärdat först när systemdiskens tillväxt motsvarar det förväntade beteendet hos avbildningar och loggar, beständiga programdata växer på den externa poolen och en saknad extern montering leder till ett säkert startfel i stället för tysta skrivningar till rotfilsystemet.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
