Se ZimaOS 1.6.2 entra in un ciclo di riavvii dopo un’operazione su un numero enorme di file e icewhale-files o icewhale-files-backup consuma diversi gigabyte di RAM, aggiorna a ZimaOS 1.7.1 o versione successiva prima di applicare mascherature permanenti ai servizi. ZimaOS 1.7.1 ha risolto ufficialmente l’uso anomalo della memoria in determinati scenari di operazioni sui file.
La segnalazione originale è comunque utile perché documenta chiaramente la catena del guasto: sono stati copiati circa 749.000 file, i servizi file sono arrivati a occupare complessivamente circa 6 GB su una macchina con 7,5 GB di RAM, la swap ha raggiunto quasi il 100% e il server si è riavviato ogni 9–10 minuti. Mascherare i servizi ha interrotto il ciclo, ma ha anche disabilitato l’app Web File e il servizio Backup.
Riconoscere il modello di saturazione della memoria
I segnali tipici includono:
- RAM quasi esaurita;
- swap quasi piena;
-
icewhale-filestra i principali processi che consumano memoria; - attese I/O molto elevate o apparenti blocchi del sistema;
- riavvii ripetuti simili a quelli causati da un watchdog dopo operazioni su un numero elevato di file.
Passaggio 1: aggiornare a ZimaOS 1.7.1 o versione successiva
Le note di rilascio ufficiali di ZimaOS 1.7.1 indicano esplicitamente una correzione per l’uso anomalo della memoria in scenari di operazioni sui file.
Questa è la correzione principale attuale. La soluzione alternativa per la versione 1.6.2 non dovrebbe essere la configurazione normale del 2026.
Passaggio 2: misurare RAM e swap
free -h
ps aux --sort=-%mem | head
swapon --showConferma che i servizi file siano effettivamente responsabili prima di disabilitare qualsiasi elemento.
Passaggio 3: verificare i riavvii recenti
journalctl --list-bootsUn intervallo ripetuto può aiutare a distinguere il comportamento del watchdog o dei ripristini da una perdita di alimentazione casuale.
Arresto d’emergenza su un sistema 1.6.2 obsoleto
Se il server non riesce a rimanere attivo abbastanza a lungo per eseguire l’aggiornamento, l’utente che ha fornito la segnalazione lo ha stabilizzato con:
sudo systemctl arresta icewhale-files.service icewhale-files-backup.service
sudo systemctl maschera icewhale-files.service icewhale-files-backup.serviceQuesta è una procedura di ripristino d’emergenza. Disabilita funzionalità native importanti. Dopo l’aggiornamento, rimuovi le mascherature e verifica normalmente i servizi attuali.
Rimuovere la mascheratura dopo il ripristino
sudo systemctl rimuove la mascheratura di icewhale-files.service icewhale-files-backup.service
sudo systemctl avvia icewhale-files.service icewhale-files-backup.serviceEsegui questa operazione solo dopo che il sistema è aggiornato a una versione corretta/attuale e hai sufficiente stabilità per osservare il comportamento della memoria.
Un numero elevato di file è diverso da una dimensione elevata dei file
749.000 file piccoli possono sottoporre metadati e indicizzazione a uno stress molto maggiore rispetto a un singolo video da 67 GB. Quando riproduci o segnali il problema, includi sia il totale dei byte sia il numero di file.
NTFS/FUSE e molti container aumentano la pressione
La macchina di origine eseguiva anche circa 38 container e utilizzava diversi volumi NTFS tramite NTFS/FUSE; molti container aumentano la pressione sulle risorse. ntfs-3g. Queste condizioni sono il contesto, non cause dimostrate. Evita di considerarle la causa principale quando la crescita della memoria osservata riguardava i servizi file di IceWhale.
Non aggiungere un MemoryMax casuale come prima correzione attuale
L'autore della fonte ha suggerito systemd MemoryMax= come miglioramento del prodotto. In una versione aggiornata, limitare artificialmente il servizio può creare nuovi errori di indicizzazione o backup se il carico di lavoro richiede legittimamente memoria.
Aggiorna prima, poi misura. Applica i limiti ai servizi solo quando comprendi il compromesso.
Mantieni AppData fuori dalla piccola unità di sistema
Il thrashing della memoria può creare un intenso I/O temporaneo. L'attuale guida allo storage delle app di ZimaOS consiglia di spostare AppData nello storage principale.
La guida alla risoluzione dei problemi di prestazioni offre un elenco di controllo più ampio delle risorse.
Domande frequenti
ZimaOS 1.7.1 ha risolto questo bug della memoria?
Ha ufficialmente risolto il consumo anomalo di memoria in determinati scenari di gestione dei file, che corrispondono direttamente al modello di errore osservato.
Devo eseguire permanentemente il masking di icewhale-files?
No. Il masking era una soluzione d'emergenza che disabilita le funzionalità File e Backup.
Perché lo swap ha peggiorato le prestazioni del server?
Quando la RAM si esaurisce, il paging aggressivo può generare un intenso I/O del disco e lunghi blocchi, soprattutto mentre i servizi file stanno già analizzando o copiando un numero enorme di file.
Quali prove dovrei raccogliere se il problema continua a verificarsi?
Versione di ZimaOS, numero di file, dimensione dei dati trasferiti, stato della RAM/dello swap, processi con il maggior consumo di memoria, tipi di montaggio/filesystem e timestamp di avvio/riavvio.
