Om ZimaOS 1.6.2 hamnar i en omstartsslinga efter en omfattande filåtgärd och icewhale-files eller icewhale-files-backup använder flera gigabyte RAM, uppdaterar du till ZimaOS 1.7.1 eller senare innan du tillämpar permanenta maskeringar. ZimaOS 1.7.1 åtgärdade officiellt onormal minnesanvändning i vissa scenarier med filåtgärder.
Källrapporten är fortfarande värdefull eftersom den tydligt dokumenterar händelseförloppet: cirka 749 000 filer kopierades, filtjänsterna växte till ungefär 6 GB tillsammans på en dator med 7,5 GB RAM, växlingsutrymmet nådde nästan 100 % och servern startade om var 9–10:e minut. Maskering av tjänsterna stoppade loopen – men inaktiverade också webbappen Files och tjänsten Backup.
Identifiera mönstret med minnesöverbelastning
Typiska tecken är:
- RAM-minnet nästan slut;
- växlingsutrymmet nästan fullt;
-
icewhale-filesbland de processer som använder mest minne; - mycket hög I/O-väntetid eller uppenbara systemlåsningar;
- upprepade omstarter som liknar watchdog-återställningar efter filåtgärder med ett stort antal filer.
Steg 1: Uppdatera till ZimaOS 1.7.1 eller senare
De officiella versionsanteckningarna för ZimaOS 1.7.1 listar uttryckligen en korrigering för onormal minnesanvändning i scenarier med filåtgärder.
Detta är den primära aktuella lösningen. Lösningen för 1.6.2 bör inte vara din normala konfiguration under 2026.
Steg 2: Mät RAM och växlingsutrymme
free -h
ps aux --sort=-%mem | head
swapon --showBekräfta att filtjänsterna faktiskt är ansvariga innan du inaktiverar något.
Steg 3: Kontrollera nyliga omstarter
journalctl --list-bootsEtt återkommande intervall kan hjälpa till att skilja mellan watchdog-/återställningsbeteende och slumpmässiga strömavbrott.
Nödstopp på ett gammalt 1.6.2-system
Om servern inte kan vara igång tillräckligt länge för att uppdateras stabiliserade källanvändaren den med:
sudo systemctl stop icewhale-files.service icewhale-files-backup.service
sudo systemctl mask icewhale-files.service icewhale-files-backup.serviceDetta är en åtgärd för nödsituationer. Den inaktiverar viktig inbyggd funktionalitet. Efter uppdateringen tar du bort maskeringarna och testar de aktuella tjänsterna normalt.
Ta bort maskering efter återställning
sudo systemctl unmask icewhale-files.service icewhale-files-backup.service
sudo systemctl start icewhale-files.service icewhale-files-backup.serviceGör detta endast efter att systemet kör en korrigerad/aktuell version och du har tillräcklig stabilitet för att observera minnesbeteendet.
Många filer skiljer sig från stora filer
749 000 små filer kan belasta metadata/indexering betydligt mer än en enda video på 67 GB. När du återskapar eller rapporterar problemet ska du ange både totalt antal byte och antal filer.
NTFS/FUSE och många containrar ökar belastningen
Källsystemet körde även cirka 38 containrar och flera NTFS-volymer via ntfs-3g. Dessa förhållanden är kontext, inte bevisade orsaker. Undvik att göra dem till grundorsaken när den observerade minnesökningen fanns i IceWhales filtjänster.
Lägg inte till ett godtyckligt MemoryMax som första aktuella åtgärd
Källförfattaren föreslog systemd MemoryMax= som en produktförbättring. I en aktuell version kan en konstgjord begränsning av tjänsten skapa nya fel vid indexering eller säkerhetskopiering om arbetsbelastningen faktiskt behöver minne.
Uppdatera först och mät sedan. Tillämpa endast tjänstbegränsningar när du förstår avvägningen.
Håll AppData borta från den lilla systemenheten
Minnesbelastning kan orsaka kraftig tillfällig I/O. Den aktuella guiden för app lagring i ZimaOS rekommenderar att AppData flyttas till huvudlagringen.
I guiden för prestandafelsökning finns en bredare checklista över resurser.
Vanliga frågor
Åtgärdade ZimaOS 1.7.1 det här minnesfelet?
Den åtgärdade officiellt onormal minnesanvändning i vissa scenarier för filåtgärder, vilket direkt överlappar det ursprungliga felmönstret.
Bör jag maskera icewhale-files permanent?
Nej. Maskering var en akut nödlösning som inaktiverar funktionerna Filer och Säkerhetskopiering.
Varför gjorde swap servern sämre?
När RAM-minnet tar slut kan aggressiv växling till swap orsaka kraftig disk-I/O och långa låsningar, särskilt när fil tjänster redan skannar eller kopierar enorma mängder filer.
Vilka bevis bör jag samla in om det fortfarande händer?
ZimaOS-version, antal filer, överföringsstorlek, RAM-/swap-status, processer som använder mest minne, monterings-/filsystemstyper samt tidsstämplar för uppstart/omstart.
