Un file di swap ZimaOS di grandi dimensioni non equivale a una pressione attiva sulla memoria e cancellarlo non è il modo corretto per recuperare spazio sul disco di avvio. Controlla l’uso effettivo dello swap, la pressione sulla memoria, l’utilizzo del disco da parte di Docker, i log e la posizione di AppData prima di modificare la configurazione dello swap.
La discussione originale del 2026 attribuiva a un file .swap da 3,8 GB la quasi totale occupazione di un disco di avvio da 48 GB, ma i calcoli mostravano che lo swap rappresentava solo una piccola parte dello spazio mancante. In seguito il sistema ha recuperato circa 20 GB, il che fa pensare più a una pulizia temporanea di Docker o della cache che a una riduzione dello swap.
Dimensioni dello swap riservate e utilizzo effettivo
Esegui:
free -h
swapon --showUn file di swap da 4 GB può esistere sul disco mentre ne viene utilizzata solo una piccola parte. Le dimensioni del file rappresentano la capacità riservata; non significa che la RAM abbia superato di 4 GB la capacità disponibile.
Trova cosa sta riempiendo il disco di sistema
Esegui:
df -h
du -xh /var/lib/docker --max-depth=1 2>/dev/null | sort -hI livelli delle immagini Docker, gli overlay scrivibili, i log, le cache e i dati temporanei possono occupare il piccolo disco di sistema anche quando i contenuti multimediali delle applicazioni sono mappati altrove.
Mantieni AppData fuori dall’unità di sistema
La guida attuale ai dati delle applicazioni di ZimaOS raccomanda esplicitamente di impostare la posizione dei dati delle applicazioni su uno spazio di archiviazione invece di riempire l’unità di sistema.
Questo non elimina tutto l’utilizzo del sistema Docker, ma impedisce che i database delle applicazioni e le cache multimediali consumino per impostazione predefinita il dispositivo di avvio.
Controlla i log dei container
Un container rumoroso può far crescere rapidamente i log JSON. Controlla l’utilizzo del disco da parte di Docker e le dimensioni dei log dei container prima di eliminare file casualmente.
Se la causa è una determinata applicazione, correggi la relativa gestione dei log o ruota i log invece di eliminare manualmente quelli attivi.
Un utilizzo elevato dello swap può comunque indicare pressione sulla RAM
Se free -h mostra poca memoria disponibile e lo swap è utilizzato attivamente, individua i processi che consumano RAM. Database pesanti, indicizzazione delle foto, carichi di lavoro IA e macchine virtuali possono spingere verso lo swap un sistema con poca memoria.
Non disabilitare lo swap solo per nascondere il sintomo
Lo swap può mantenere operativo il sistema durante brevi picchi di utilizzo della memoria. Disabilitarlo su un server con memoria limitata può trasformare un rallentamento in terminazioni per esaurimento della memoria.
Quando aggiungere RAM
Aggiungi RAM quando i carichi di lavoro sostenuti esauriscono costantemente la memoria fisica e i servizi importanti utilizzano intensamente il paging. Non aumentare la RAM solo perché esiste un file di swap.
La guida alla risoluzione dei problemi di prestazioni aiuta a evitare di considerare ogni server lento come un problema di RAM.
Misura la pressione sulla memoria nel tempo
Una singola istantanea di free -h può essere fuorviante, perché Linux utilizza deliberatamente la RAM libera per la cache. Controlla la memoria disponibile e verifica se l’attività di swap-in e swap-out continua durante il carico di lavoro.
Se gli strumenti disponibili sul sistema mostrano uno swapping prolungato mentre il server è lento, individua l’applicazione o la macchina virtuale che sta consumando memoria invece di concentrarti solo sulle dimensioni del file di swap.
Le immagini Docker consumano comunque spazio di sistema
Spostare AppData in /DATA non sposta ogni livello delle immagini Docker né tutti i file di runtime. Installare e aggiornare molte applicazioni può quindi far crescere il disco di sistema anche quando tutti i volumi visibili all’utente puntano altrove.
Prima di eseguire una pulizia, usa la visualizzazione dell’utilizzo del disco integrata in Docker per distinguere tra immagini, container, volumi locali e cache di compilazione. Rimuovi solo gli oggetti che sai essere inutilizzati.
Verifica se un disco di sistema piccolo è il problema strutturale
Un disco di avvio da 48 GB può funzionare, ma lascia poco margine per più immagini di applicazioni, aggiornamenti, log e operazioni temporanee. Se il sistema si avvicina ripetutamente al 100% nonostante una pulizia corretta, un disco di sistema più grande o lo spostamento di più carichi di lavoro persistenti nello spazio di archiviazione principale potrebbe essere la soluzione sostenibile.
Lo spazio libero ridotto può causare problemi secondari
Quando l’area di sistema scrivibile è quasi piena, gli aggiornamenti delle applicazioni, le scritture dei database, i log e i file temporanei possono non riuscire in modi che sembrano non correlati allo spazio di archiviazione. Considera il poco spazio libero un rischio operativo anche se su un altro array sono disponibili terabyte.
Domande frequenti
Perché lo spazio libero sul disco è tornato disponibile durante la notte?
I livelli Docker temporanei, le cache, i log o i processi di pulizia potrebbero aver liberato spazio. Questo non significa che il file di swap si sia ridotto.
Devo eliminare il file .swap?
No. Controlla prima l’utilizzo attivo dello swap e quali elementi stanno realmente consumando spazio sul disco.
È normale avere 3–4 GB di swap?
La presenza di un file di swap di qualche gigabyte non è insolita. Ciò che conta è la quantità di swap utilizzata attivamente e se la pressione sulla memoria è prolungata.
Perché il disco di avvio è ancora occupato se AppData si trova in /DATA?
I metadati del motore Docker, i livelli delle immagini, gli overlay di runtime, i log e i file di sistema si trovano comunque al di fuori dei dati delle applicazioni mappati.
