Waarom behoudt een actieve container zijn oude geheugenlimiet nadat het Compose-bestand is gewijzigd?
Een actief containerproces behoudt de oude geheugenlimiet wanneer de bewerkte Compose-configuratie nooit is toegepast op de live cgroup van die container.
Het wijzigen van YAML past een bestaande container niet automatisch aan, en een gewone herstart start dezelfde container met dezelfde configuratie die bij het aanmaken is vastgelegd. Verwarring ontstaat ook doordat een harde geheugenlimiet wordt vergeleken met een reservering, swaptoewijzing, de bovenliggende systemd-scope of een heapinstelling van de toepassing. Controleer de effectieve cgroup-waarde en container-ID voordat je concludeert dat Docker de wijziging heeft genegeerd.
Lees de limiet van de live cgroup in plaats van de YAML te vertrouwen
Noteer de container-ID, aanmaaktijd, Docker-inspectie-uitvoer, cgroup-versie en de geheugenbeheerbestanden die door het actieve proces worden gebruikt.
De Linux-kernel definieert memory.max als de harde limiet van de cgroup, terwijl memory.high terugwinningsdruk toepast zonder dezelfde absolute bovengrens te zijn.
Als de live cgroup nog steeds de oude waarde bevat, is de configuratie niet toegepast. Bevat deze de nieuwe waarde, maar wijkt de monitoring af, controleer dan eenheden, cacheboekhouding, swap en metrieken op applicatieniveau.
Maak onderscheid tussen herstarten en containers opnieuw aanmaken
Vergelijk de container-ID vóór en na de opdracht waarmee je de wijziging hebt geïmplementeerd. Noteer of de opdracht restart, up, create, een NAS-interfaceactie of een directe Docker-update was.
Docker vermeldt dat Compose restart configuratiewijzigingen niet toepast, omdat hiermee de bestaande servicecontainers opnieuw worden gestart.
Gebruik een gecontroleerde Compose-update die de service opnieuw aanmaakt, of indien passend een ondersteunde live-update van resources. Bewaar de oude inspectie-uitvoer, zodat je het gewijzigde veld kunt verifiëren.
Valideer het uiteindelijke Compose-model en het geheugenveld
Genereer de effectieve Compose-configuratie nadat alle bestanden, profielen en omgevingssubstituties zijn toegepast. Controleer of de limiet bij de actieve service hoort.
De Compose-specificatie definieert mem_limit als geheugenlimiet voor een service en vereist consistentie wanneer ook gelijkwaardige deploy-limieten zijn opgegeven.
Een waarde in een ongebruikt override-bestand, inactief profiel, verkeerd gespelde service of andere Stack-interface wijzigt het geïmplementeerde model niet. Vergelijk de gegenereerde configuratie met de Docker-inspectie.
Scheid harde limiet, reservering en swap
Noteer de harde geheugenlimiet, reservering of zachte limiet, swaplimiet, huidig gebruik, piekgebruik en OOM-gebeurtenissen. Behandel niet elke geheugenwaarde alsof deze dezelfde bovengrens is.
De documentatie over resourcebeheer van systemd maakt onderscheid tussen MemoryHigh en MemoryMax en laat zien dat bovenliggende cgroups extra limieten kunnen opleggen aan services en containers.
Een container kan een reservering lijken te overschrijden, omdat een reservering niet hetzelfde is als een harde limiet. De container kan ook swap of paginacache gebruiken die een dashboard niet meetelt of afzonderlijk rapporteert.
Controleer of de runtime-heap zijn eigen bovengrens gebruikt
Noteer voor Java-toepassingen de containerbewuste JVM-detectie, maximale heap, direct geheugen, metaspace, threadstacks en de flags die door de image- of applicatieconfiguratie worden doorgegeven.
Oracle documenteert dat de JVM zijn heapgrootte afstemt op beschikbare geheugenbeperkingen en toestaat dat MaxRAMPercentage het heappercentage instelt.
Het wijzigen van de containerlimiet leidt mogelijk niet tot de verwachte applicatieheap wanneer een expliciete -Xmx of percentage van kracht blijft. Heapgeheugen is bovendien niet het totale geheugengebruik van het proces.
Controleer Node.js en andere limieten op applicatieniveau
Inspecteer runtimeflags, omgevingsvariabelen, aantallen workers, caches en interne geheugendoelen. Vergelijk deze met de limiet van het besturingssysteem.
Node.js documenteert max-old-space-size als V8-heaplimiet, die ongewijzigd kan blijven nadat de container een grotere of kleinere cgroup-toewijzing heeft gekregen.
Een containerlimiet beschermt de host; hiermee wordt niet automatisch elke toepassing afgestemd. Stel de runtime lager in dan de containerlimiet, met ruimte voor native toewijzingen en bestandssysteemcache.
Pas één wijziging toe en verifieer deze onder gecontroleerde belasting
Genereer het uiteindelijke Compose-model, maak alleen de betrokken service opnieuw aan, bevestig de nieuwe container-ID en live cgroup en voer vervolgens een begrensde werklast uit terwijl je gebruik en OOM-gebeurtenissen monitort.
Het artikel van ZimaSpace Tech & AI Hub, legt uit wat er gebeurt bij het bereiken van een actieve containerlimiet; dit artikel richt zich op het aantonen dat een gewijzigde limiet daadwerkelijk is geïmplementeerd.
Het probleem is opgelost wanneer de gegenereerde configuratie, containerinspectie, cgroup-bestanden, runtime-heap en waargenomen foutgrens na een herstart allemaal overeenkomen met het beoogde beleid.
Veelgestelde vragen
Past het herstarten van een container een gewijzigde Compose-geheugenlimiet toe?
Nee. Een herstart gebruikt normaal gesproken dezelfde configuratie van de bestaande container. Maak de service opnieuw aan of gebruik een ondersteunde live-update.
Kan een container zijn harde geheugenlimiet tijdelijk overschrijden?
Kernelboekhouding en terugwinning kunnen kortstondig waarden rond of iets boven een grens laten zien, maar aanhoudend niet-terugwinbaar gebruik bij de harde limiet leidt tot cgroup-OOM-afhandeling.
Waarom meldt de app nog steeds de oude heapgrootte?
De runtime van de toepassing kan een expliciete heapflag gebruiken of een percentage alleen bij het opstarten berekenen. Maak de container opnieuw aan of start de toepassing opnieuw nadat je de containerlimiet hebt gevalideerd.
Aanbevolen producten
Ondersteuning & Tips
Meer om te lezen
Waarom herstelt een Docker-volume de bestandsinhoud, maar gaan uitgebreide bestandskenmerken verloren?
Een diagnose van volumeterugzetting met een inventaris van xattrs, tar- en Rsync-opties, naamruimten, ondersteuning voor bestemmingen, machtigingen, labels, app-metagegevens en tests.
Waarom maakt het herstarten van een reverse proxy elke sessie voor één zelfgehoste app ongeldig?
Een diagnose van sessieverlies met aandacht voor de reikwijdte van herstarts, cookie-eigenaarschap, geheimenrotatie, cachegestuurde sessies, sticky routing, authenticatiegateways en herstel.
Waarom wordt een Compose-netwerkalias niet meer opgelost nadat de stack onder een nieuwe projectnaam opnieuw is aangemaakt?
Een Compose-DNS-diagnose over projectnamen, netwerkgebonden aliassen, externe netwerken, ingebouwde DNS, proxykoppeling, verouderde eindpunten en opnieuw aanmaken.
