In sintesi: “ZimaOS usa più RAM dopo la 1.6” non è abbastanza specifico: individua il processo o il container
Il sistema da 8 GB mostrava ancora un utilizzo elevato della memoria dopo il passaggio dalla versione 1.6.0-beta2 alla versione stabile. Questo esclude la semplice spiegazione secondo cui si trattava soltanto dell’overhead della beta. Il passo successivo utile è attribuire l’utilizzo: quale container, cache o processo host occupa la memoria e il sistema è davvero sotto pressione?
Inizia dalla memoria disponibile, non solo dalla percentuale della dashboard
free -h
docker stats --no-stream
ps aux --sort=-%mem | head -20
dmesg | grep -i -E 'oom|out of memory'Linux utilizza la RAM altrimenti inattiva per la cache. Un valore elevato di “used” con una memoria available adeguata e senza pressione da OOM o swap è diverso da una perdita di memoria. La contabilizzazione della memoria di Linux è il riferimento upstream.
I totali dei container spiegano solo una parte dell’host
Lo screenshot mostra diversi container che consumano centinaia di megabyte ciascuno, ma la loro somma non corrisponde necessariamente al totale dell’host. Le metriche della memoria Docker, la cache del kernel, la page cache e i servizi non containerizzati appartengono a livelli separati di contabilizzazione. La statistica dei container Docker illustra la visualizzazione dei container.
Non dare per scontato che la versione stabile 1.6.0 includesse una correzione generale per una perdita di memoria
Le note di rilascio dell’attuale versione 1.6.0 elencano correzioni relative allo storage, all’avvio di Docker, a Files e alla rete, ma non documentano una correzione generale per una perdita di memoria. Pertanto, la diagnosi attuale dovrebbe basarsi sulle evidenze, invece di affermare che “con l’aggiornamento il problema è risolto”.
Le modifiche di ZimaOS 1.6 forniscono il contesto attuale della versione.
Quando si tratta davvero di una perdita di memoria
Monitora lo stesso processo per diverse ore. Una perdita è più probabile quando un processo cresce in modo monotono, la memoria disponibile diminuisce, l’utilizzo dello swap aumenta o il kernel inizia a terminare i processi. Se l’utilizzo della memoria si stabilizza e il sistema rimane reattivo, potrebbe semplicemente trattarsi di un working set stabile di dimensioni maggiori.
I requisiti delle app ZimaOS aiutano a capire se l’insieme di app installate è semplicemente troppo grande per un host da 8 GB.
