Om icewhale-files-backup växer till flera gigabyte RAM och upprepade gånger utlöser OOM-killern i ZimaOS 1.7.0 bör du först uppdatera till ZimaOS 1.7.1 eller senare. IceWhales versionsinformation för 1.7.1 anger uttryckligen att onormal minnesanvändning i vissa filhanteringsscenarier samt problem med misslyckade eller avbrutna säkerhetskopieringar har åtgärdats.
Diskussionstråden dokumenterade en allvarlig regression i 1.7.0: minnesanvändningen ökade från ungefär 3,5 GB till mer än 10 GB, kärnan avslutade Backup-processen, Restart=always startade den igen och cykeln destabiliserade servern. Att maskera tjänsten stoppade loopen, men var endast en akut tillfällig lösning.
Identifiera OOM-loopen
journalctl -k | grep -i -E 'oom|out of memory|killed process'
ps aux --sort=-%mem | head
free -hOm Backup-processen upprepade gånger blir den största minneskonsumenten kan omstartsloopen svälta ut Docker och andra tjänster.
Uppdatera till 1.7.1 eller senare
Den officiella versionsinformationen för ZimaOS 1.7.1 listar korrigeringar för onormal minnesanvändning och säkerhetskopieringsuppgifter som kunde misslyckas eller avbrytas.
Akut återställning i 1.7.0
sudo systemctl stop icewhale-files-backup.service
sudo systemctl disable icewhale-files-backup.service
sudo systemctl mask icewhale-files-backup.serviceMaskering var nödvändig eftersom ett normalt stopp eller en inaktivering inte alltid förhindrade att tjänsten startades igen av tjänstens omstartspolicy.
Förstå vad maskering innebär
Maskering inaktiverar den inbyggda Backup-funktionen. Använd den endast för att stabilisera en obrukbar värd tillräckligt länge för att uppdatera systemet eller återställa data.
Avmaskera efter uppdatering
sudo systemctl unmask icewhale-files-backup.service
sudo systemctl enable icewhale-files-backup.service
sudo systemctl start icewhale-files-backup.serviceKör sedan en liten, kontrollerad säkerhetskopiering medan du övervakar RAM och växlingsutrymme.
USB-säkerhetskopieringar var en vanlig utlösande faktor
Flera användare rapporterade liknande beteenden med USB-mål för säkerhetskopiering. Det underlättar reproduktion av felet, men bevisar inte att själva kabinettet orsakade det.
Verifiera att säkerhetskopieringen är komplett
Jämför antalet filer i källan och målet och genomför ett återställningstest. guiden för verifiering av säkerhetskopior hjälper dig att minska beroendet av ett enda jobb.
Kontrollera om Docker skadades av minnesbrist
I tråden blev Docker-applikationerna till slut otillgängliga efter långvarig minnespress. När värden är stabil, verifiera docker ps, Docker-demonen och kritiska containrar innan du startar en stor säkerhetskopiering igen.
Börja med en liten säkerhetskopiering efter uppdateringen
Kör inte omedelbart om jobbet på flera terabyte eller USB-jobbet som utlöste felet. Skapa en liten testuppgift, övervaka minnet i 10–20 minuter och öka sedan gradvis antalet filer och den totala storleken. Då blir det lättare att se om den korrigerade tjänsten håller minnesanvändningen inom rimliga gränser.
Antalet filer är lika viktigt som antalet byte
Hundratusentals små filer kan skapa betydligt mer metadataarbete än ett fåtal stora mediefiler. När du skickar in en supportförfrågan bör du ange både det totala antalet byte och det ungefärliga antalet filer.
Behåll en oberoende säkerhetskopieringsväg under testningen
Om den inbyggda Backup-funktionen tidigare varit ofullständig eller instabil bör du behålla en annan bekräftat fungerande kopia med ett separat verktyg eller mål tills ett återställningstest bekräftar att det aktuella ZimaOS-jobbet är tillförlitligt.
Spara loggar från före och efter åtgärden
Spara OOM-meddelanden, processerna med högst minnesanvändning, ZimaOS-versionen och typen av säkerhetskopieringsmål före uppdateringen. Upprepa sedan samma kontrollerade arbetsbelastning efter 1.7.1+ och jämför minnesökningen. Då får du bevis på att regressionen är löst i stället för att enbart förlita dig på att ”servern känns stabil”.
Om minnesanvändningen fortfarande växer utan gräns i den korrigerade versionen ska du stoppa uppgiften och skicka mätningarna före och efter uppdateringen till supporten.
Vanliga frågor
Bekräftades minnesläckan av flera användare?
Ja. Flera användare rapporterade samma beteende i 1.7.0.
Åtgärdade 1.7.1 den här typen av problem?
Ja. Den officiella ändringsloggen innehåller korrigeringar för minne och säkerhetskopiering som direkt överlappar detta problem.
Bör jag återgå till 1.6.2?
Det var en tillfällig lösning före 1.7.1. Aktuella användare bör föredra den korrigerade stabila versionen.
Hur vet jag att åtgärden fungerade?
Kör en kontrollerad säkerhetskopiering medan du övervakar minne, växlingsutrymme, loggar och att målet innehåller alla data.
