Varför behåller en körande container sin gamla minnesgräns efter att Compose-filen har ändrats?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Why Does a Running Container Keep Its Old Memory Limit After the Compose File Changes? - Zima Store Online

En container som körs behåller sin gamla minnesgräns när den redigerade Compose-konfigurationen aldrig tillämpades på den containerns aktiva cgroup.

Att ändra YAML ändrar inte en befintlig container automatiskt, och en vanlig omstart startar samma container med samma konfiguration som skapades vid skapandet. Förvirring uppstår också när man jämför en hård minnesgräns med en reservation, ett swap-utrymme, en överordnad systemd-scope eller en inställning för programmets heap. Diagnostisera det effektiva cgroup-värdet och container-ID:t innan du drar slutsatsen att Docker ignorerade ändringen.

Läs den aktiva cgroup-gränsen i stället för att lita på YAML

Notera container-ID, skapandetid, Docker-inspektionsdata, cgroup-version och de minneskontrollfiler som används av den körande processen.

Linux-kärnan definierar memory.max som cgroupens hårda gräns, medan memory.high skapar återvinningspress utan att fungera som samma absoluta tak.

Om den aktiva cgroupen fortfarande innehåller det gamla värdet tillämpades inte konfigurationen. Om den innehåller det nya värdet men övervakningen visar något annat, kontrollerar du enheter, cache-redovisning, swap och mätvärden på programnivå.

Skilj på omstart och återskapande av containern

Jämför container-ID:t före och efter kommandot som användes för att distribuera ändringen. Notera om kommandot var restart, up, create, en åtgärd i NAS-gränssnittet eller en direkt Docker-uppdatering.

Docker anger att Compose restart inte tillämpar konfigurationsändringar, eftersom det startar om de befintliga servicecontainrarna.

Använd en kontrollerad Compose-uppdatering som återskapar tjänsten, eller en stödd uppdatering av resurser medan containern körs när det är lämpligt. Spara den gamla inspektionsinformationen så att det ändrade fältet kan verifieras.

Validera den slutliga Compose-modellen och minnesfältet

Rendera den effektiva Compose-konfigurationen efter att alla filer, profiler och miljösubstitutioner har tillämpats. Kontrollera att gränsen hör till den aktiva tjänsten.

Compose-specifikationen definierar mem_limit som en minnesgräns för tjänsten och kräver överensstämmelse när motsvarande deploy-gränser också anges.

Ett värde i en oanvänd åsidosättningsfil, en inaktiv profil, en felstavad tjänst eller ett annat Stack-gränssnitt ändrar inte den distribuerade modellen. Jämför den renderade konfigurationen med Dockers inspektionsdata.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Skilj på hård gräns, reservation och swap

Notera den hårda minnesgränsen, reservationen eller den mjuka gränsen, swap-gränsen, aktuell användning, maximal användning och OOM-händelser. Behandla inte alla minnesrelaterade värden som samma tak.

Systemds dokumentation om resurskontroll skiljer MemoryHigh från MemoryMax och visar att överordnade cgroups kan införa ytterligare gränser för tjänster och containrar.

En container kan verka överskrida en reservation eftersom en reservation inte är samma sak som ett hårt tak. Den kan också använda swap eller sidcache som en instrumentpanel utelämnar eller redovisar separat.

Kontrollera om runtime-heapen har ett eget tak

För Java-program noterar du containeranpassad JVM-detektering, maximal heap, direktminne, metaspace, trådstackar och de flaggor som skickas av avbildningen eller programmets konfiguration.

Oracle dokumenterar att JVM:en dimensionerar sin heap utifrån tillgängliga minnesbegränsningar och tillåter MaxRAMPercentage att ange heapens andel.

Att ändra containergränsen ger kanske inte den förväntade programheapen när en uttrycklig -Xmx eller procentsats fortfarande används. Heapminne är dessutom inte processens totala minnesanvändning.

Kontrollera Node.js och andra gränser på programnivå

Granska runtime-flaggor, miljövariabler, antal arbetare, cacheminnen och interna minnesmål. Jämför dem med operativsystemets gräns.

Node.js dokumenterar max-old-space-size som en V8-heapgräns, vilken kan förbli oförändrad även efter att containern har fått ett större eller mindre cgroup-utrymme.

En containergräns skyddar värden; den finjusterar inte automatiskt alla program. Ställ in runtime-gränsen under containerns tak och lämna utrymme för inhemska allokeringar och filsystemcache.

Tillämpa en ändring och verifiera under kontrollerad belastning

Rendera den slutliga Compose-modellen, återskapa endast den berörda tjänsten, bekräfta det nya container-ID:t och den aktiva cgroupen, och kör sedan en avgränsad arbetsbelastning medan du övervakar användning och OOM-händelser.

ZimaSpace Tech & AI Hubs artikel förklarar vad som händer när en aktiv containergräns nås; den här artikeln fokuserar på att bevisa att en ändrad gräns faktiskt distribuerades.

Problemet är löst när den renderade konfigurationen, containerinspektionen, cgroup-filerna, runtime-heapen och den observerade felgränsen efter omstart överensstämmer med den avsedda policyn.

Vanliga frågor

Tillämpas en ändrad Compose-minnesgräns när en container startas om?

Nej. En omstart använder normalt samma befintliga containerkonfiguration. Återskapa tjänsten eller använd en stödd uppdatering medan den körs.

Kan en container tillfälligt överskrida sin hårda minnesgräns?

Kärnans redovisning och återvinning kan kortvarigt visa värden nära eller något över en gräns, men ihållande minnesanvändning som inte kan återvinnas vid den hårda gränsen leder till cgroup-hantering av OOM.

Varför rapporterar programmet fortfarande den gamla heapstorleken?

Programmets runtime kan ha en uttrycklig heapflagga eller beräkna en procentsats endast vid start. Återskapa eller starta om det efter att du har validerat containergränsen.