If ZimaOS 1.6.2 enters a reboot loop after a huge file operation and icewhale-files or icewhale-files-backup consumes several gigabytes of RAM, update to ZimaOS 1.7.1 or newer before applying permanent service masks. ZimaOS 1.7.1 officially fixed abnormal memory usage in certain file-operation scenarios.
Wenn ZimaOS 1.6.2 nach einem umfangreichen Dateivorgang in eine Neustartschleife gerät und icewhale-files oder icewhale-files-backup mehrere Gigabyte RAM verbraucht, aktualisieren Sie auf ZimaOS 1.7.1 oder neuer, bevor Sie dauerhafte Dienstmaskierungen anwenden. ZimaOS 1.7.1 hat die abnormale Speichernutzung bei bestimmten Dateivorgängen offiziell behoben.
Das ursprüngliche Problemprotokoll ist weiterhin wertvoll, da es die Fehlerkette klar dokumentiert: Etwa 749.000 Dateien wurden kopiert, die Dateidienste wuchsen auf einem Rechner mit 7,5 GB RAM zusammen auf ungefähr 6 GB an, der Swap war fast zu 100 % belegt und der Server startete alle 9–10 Minuten neu. Durch die Maskierung der Dienste wurde die Schleife beendet – gleichzeitig wurden jedoch die Web-App „Dateien“ und der Backup-Dienst deaktiviert.
Typische Anzeichen sind:
- RAM fast erschöpft;
- Swap nahezu vollständig belegt;
-
icewhale-filesunter den Prozessen mit dem höchsten Speicherverbrauch; - sehr hohe I/O-Wartezeiten oder scheinbare Systemstillstände;
- wiederholte, Watchdog-ähnliche Neustarts nach Vorgängen mit großen Dateimengen.
Schritt 1: Auf ZimaOS 1.7.1 oder neuer aktualisieren
Die offiziellen Versionshinweise zu ZimaOS 1.7.1 nennen ausdrücklich eine Behebung der abnormalen Speichernutzung bei Dateivorgängen.
Das ist die derzeit wichtigste Lösung. Die Umgehungslösung für 1.6.2 sollte nicht Ihre normale Konfiguration für 2026 sein.
Schritt 2: RAM und Swap messen
free -h
ps aux --sort=-%mem | head
swapon --showStellen Sie sicher, dass die Dateidienste tatsächlich verantwortlich sind, bevor Sie etwas deaktivieren.
Schritt 3: Kürzliche Neustarts überprüfen
journalctl --list-bootsEin wiederkehrendes Intervall kann dabei helfen, Watchdog-/Reset-Verhalten von zufälligem Stromausfall zu unterscheiden.
Notstopp auf einem alten 1.6.2-System
Wenn der Server nicht lange genug aktiv bleiben kann, um aktualisiert zu werden, hat der ursprüngliche Benutzer ihn mit folgendem Befehl stabilisiert:
sudo systemctl stop icewhale-files.service icewhale-files-backup.service
sudo systemctl mask icewhale-files.service icewhale-files-backup.serviceDies ist eine Notfallmaßnahme zur Wiederherstellung. Sie deaktiviert wichtige native Funktionen. Entfernen Sie die Maskierungen nach der Aktualisierung und testen Sie die aktuellen Dienste anschließend normal.
Nach der Wiederherstellung die Maskierung aufheben
sudo systemctl unmask icewhale-files.service icewhale-files-backup.service
sudo systemctl start icewhale-files.service icewhale-files-backup.serviceFühre dies erst durch, nachdem das System auf einer behobenen/aktuellen Version läuft und ausreichend stabil ist, um das Speicherverhalten zu beobachten.
Eine große Dateianzahl ist etwas anderes als eine große Dateigröße
749.000 kleine Dateien können Metadaten und Indizierung deutlich stärker belasten als ein einzelnes 67-GB-Video. Führe bei der Reproduktion oder Meldung des Problems sowohl die Gesamtgröße in Bytes als auch die Dateianzahl an.
NTFS/FUSE und zahlreiche Container erhöhen den Speicherdruck
Auf dem Quellsystem liefen außerdem etwa 38 Container und mehrere NTFS-Volumes über NTFS/FUSE; zahlreiche Container erhöhen den Speicherdruck zusätzlich. ntfs-3g. Diese Bedingungen dienen als Kontext und sind keine nachgewiesenen Ursachen. Vermeide es, sie als eigentliche Ursache darzustellen, wenn das beobachtete Speicherwachstum in den IceWhale-Dateidiensten auftrat.
Füge nicht als erste aktuelle Maßnahme ein beliebiges MemoryMax hinzu
Der Autor der Quelle schlug systemd vor MemoryMax= als Produktverbesserung. Bei einer aktuellen Version kann eine künstliche Begrenzung des Dienstes neue Fehler bei der Indizierung oder bei Backups verursachen, wenn die Arbeitslast legitimerweise Speicher benötigt.
Zuerst aktualisieren, dann messen. Beschränke Dienste nur, wenn du den damit verbundenen Kompromiss verstehst.
AppData nicht auf dem kleinen Systemlaufwerk speichern
Speicher-Thrashing kann eine hohe temporäre I/O-Last verursachen. Der aktuelle Leitfaden zum ZimaOS-App-Speicher empfiehlt, AppData auf dem Hauptspeicher abzulegen.
Der Leitfaden zur Fehlerbehebung bei Leistungsproblemen bietet eine umfassendere Checkliste für Ressourcen.
FAQ
Hat ZimaOS 1.7.1 diesen Speicherfehler behoben?
Es behob offiziell die anomale Speichernutzung in bestimmten Dateivorgangsszenarien, die direkt mit dem ursprünglichen Fehlerbild übereinstimmen.
Sollte ich icewhale-files dauerhaft maskieren?
Nein. Durch das Maskieren wird als Notlösung die Funktionalität von Dateien und Backups deaktiviert.
Warum hat der Swap den Server verschlechtert?
Wenn der RAM erschöpft ist, kann aggressives Paging eine hohe Festplatten-I/O-Last und lange Verzögerungen verursachen, insbesondere wenn die Dateidienste bereits große Dateimengen scannen oder kopieren.
Welche Belege sollte ich sammeln, wenn das Problem weiterhin auftritt?
ZimaOS-Version, Dateianzahl, Übertragungsgröße, RAM-/Swap-Status, speicherintensivste Prozesse, Mount-/Dateisystemtypen sowie Start-/Neustartzeitstempel.
