Als icewhale-files-backup op ZimaOS 1.7.0 tot meerdere gigabytes RAM groeit en herhaaldelijk de OOM-killer activeert, werk dan eerst bij naar ZimaOS 1.7.1 of nieuwer. In de releaseopmerkingen van IceWhale voor 1.7.1 staat expliciet dat abnormaal geheugengebruik in bepaalde scenario's voor bestandsbewerkingen en problemen met mislukte of onderbroken back-ups zijn opgelost.
In de brondiscussie werd een ernstige regressie in 1.7.0 beschreven: het geheugengebruik groeide van ongeveer 3,5 GB naar meer dan 10 GB, waarna de kernel Backup beëindigde. Restart=always startte de service opnieuw, maar deze cyclus destabiliseerde de server. Het maskeren van de service stopte de lus, maar was slechts een noodoplossing.
Herken de OOM-lus
journalctl -k | grep -i -E 'oom|out of memory|killed process'
ps aux --sort=-%mem | head
free -hAls het Backup-proces steeds opnieuw de grootste geheugengebruiker is, kan de herstartlus Docker en andere services van geheugen beroven.
Werk bij naar 1.7.1 of nieuwer
De officiële releaseopmerkingen van ZimaOS 1.7.1 vermelden oplossingen voor abnormaal geheugengebruik en back-uptaken die konden mislukken of worden onderbroken.
Noodherstel op 1.7.0
sudo systemctl stop icewhale-files-backup.service
sudo systemctl disable icewhale-files-backup.service
sudo systemctl mask icewhale-files-backup.serviceMaskeren was noodzakelijk omdat normaal stoppen of uitschakelen niet altijd voorkwam dat de service opnieuw werd gestart door het herstartbeleid.
Begrijp wat maskeren uitschakelt
Maskeren schakelt de ingebouwde Backup uit. Gebruik dit alleen om een onbruikbare host lang genoeg te stabiliseren om bij te werken of gegevens te herstellen.
Maak de service na het bijwerken weer vrij
sudo systemctl unmask icewhale-files-backup.service
sudo systemctl enable icewhale-files-backup.service
sudo systemctl start icewhale-files-backup.serviceVoer daarna een kleine, gecontroleerde back-up uit terwijl je RAM en swap monitort.
Back-upbelastingen via USB waren een veelvoorkomende trigger
Meerdere gebruikers meldden vergelijkbaar gedrag met USB-back-updoelen. Dat helpt bij het reproduceren van de bug, maar bewijst niet dat de behuizing zelf de oorzaak was.
Controleer of de back-up compleet is
Vergelijk het aantal bestanden in de bron en de bestemming en voer een hersteltest uit. De handleiding voor back-upverificatie helpt de afhankelijkheid van één taak te verminderen.
Controleer of Docker is beschadigd door geheugentekort
In de discussie werden Docker-toepassingen uiteindelijk onbeschikbaar door langdurige geheugendruk. Controleer, zodra de host stabiel is, docker ps, de Docker-daemon en kritieke containers voordat je een grote back-upbelasting opnieuw start.
Begin na het bijwerken met een kleine back-up
Start niet meteen de multi-terabyte- of USB-taak opnieuw die de fout veroorzaakte. Maak een kleine testtaak, monitor het geheugen 10–20 minuten en verhoog daarna geleidelijk het aantal bestanden en de totale omvang. Zo is het eenvoudiger om te zien of de opgeloste service binnen stabiele grenzen blijft.
Het aantal bestanden is net zo belangrijk als het aantal bytes
Honderdduizenden kleine bestanden kunnen veel meer metagegevensverwerking veroorzaken dan enkele grote mediabestanden. Vermeld bij een ondersteuningsverzoek zowel het totale aantal bytes als het geschatte aantal bestanden.
Houd tijdens het testen een onafhankelijke back-uproute aan
Als de ingebouwde Backup eerder onvolledig of instabiel was, houd dan een andere bekende goede kopie aan met een afzonderlijke tool of bestemming totdat een hersteltest bevestigt dat de huidige ZimaOS-taak betrouwbaar is.
Bewaar logboeken van vóór en na de oplossing
Bewaar vóór het bijwerken de OOM-meldingen, de processen met het hoogste geheugengebruik, de ZimaOS-versie en het type back-updoel. Herhaal daarna dezelfde gecontroleerde belasting op 1.7.1+ en vergelijk de geheugengroei. Zo krijg je bewijs dat de regressie is opgelost in plaats van alleen te vertrouwen op het feit dat “de server stabiel aanvoelt”.
Als het geheugen in de opgeloste release nog steeds onbeperkt groeit, stop dan de taak en stuur die metingen van vóór en na de update naar de ondersteuning.
Veelgestelde vragen
Is het geheugenlek door meerdere gebruikers bevestigd?
Ja. Verschillende gebruikers meldden hetzelfde gedrag in 1.7.0.
Heeft 1.7.1 dit soort problemen aangepakt?
Ja. De officiële changelog bevat geheugen- en back-upoplossingen die hier rechtstreeks mee overeenkomen.
Moet ik teruggaan naar 1.6.2?
Dat was een tijdelijke oplossing vóór 1.7.1. Huidige gebruikers kunnen beter de stabiele versie met de oplossing gebruiken.
Hoe weet ik of de oplossing werkt?
Voer een gecontroleerde back-up uit terwijl je het geheugen, de swap, de logboeken en de volledigheid van de bestemming monitort.
