Jeśli proces icewhale-files-backup zużywa kilka gigabajtów pamięci RAM i wielokrotnie wywołuje mechanizm OOM killer w ZimaOS 1.7.0, najpierw zaktualizuj system do ZimaOS 1.7.1 lub nowszej wersji. W informacjach o wydaniu IceWhale dla wersji 1.7.1 wyraźnie wskazano poprawki nieprawidłowego zużycia pamięci w określonych scenariuszach operacji na plikach oraz problemów z niepowodzeniami i przerywaniem kopii zapasowych.
Wątek źródłowy dokumentował poważną regresję w wersji 1.7.0: zużycie pamięci wzrastało z około 3,5 GB do ponad 10 GB, jądro kończyło proces Backup, ustawienie Restart=always uruchamiało go ponownie, a cykl destabilizował serwer. Zamaskowanie usługi zatrzymywało pętlę, ale było tylko awaryjnym obejściem.
Rozpoznawanie pętli OOM
journalctl -k | grep -i -E 'oom|out of memory|killed process'
ps aux --sort=-%mem | head
free -hJeśli proces Backup wielokrotnie pojawia się na pierwszym miejscu pod względem zużycia pamięci, pętla ponownych uruchomień może pozbawić Dockera i inne usługi dostępnych zasobów.
Aktualizacja do wersji 1.7.1 lub nowszej
Oficjalne informacje o wydaniu ZimaOS 1.7.1 zawierają poprawki nieprawidłowego zużycia pamięci oraz zadań tworzenia kopii zapasowych, które mogły kończyć się niepowodzeniem lub być przerywane.
Awaryjne odzyskiwanie w wersji 1.7.0
sudo systemctl stop icewhale-files-backup.service
sudo systemctl disable icewhale-files-backup.service
sudo systemctl mask icewhale-files-backup.serviceZamaskowanie usługi było konieczne, ponieważ zwykłe zatrzymanie lub wyłączenie nie zawsze zapobiegało jej ponownemu uruchomieniu zgodnie z zasadami restartowania usługi.
Co powoduje zamaskowanie usługi
Zamaskowanie wyłącza wbudowaną funkcję Backup. Używaj go tylko w celu ustabilizowania niesprawnego hosta na czas aktualizacji lub odzyskiwania danych.
Usunięcie maskowania po aktualizacji
sudo systemctl unmask icewhale-files-backup.service
sudo systemctl enable icewhale-files-backup.service
sudo systemctl start icewhale-files-backup.serviceNastępnie uruchom niewielką, kontrolowaną kopię zapasową, monitorując pamięć RAM i pamięć wymiany.
Kopie zapasowe na USB były częstym wyzwalaczem problemu
Wielu użytkowników zgłaszało podobne zachowanie w przypadku miejsc docelowych kopii zapasowych podłączonych przez USB. Pomaga to odtworzyć błąd, ale nie dowodzi, że przyczyną była sama obudowa.
Weryfikacja kompletności kopii zapasowej
Porównaj liczbę plików w źródle i miejscu docelowym oraz wykonaj test przywracania. przewodnik weryfikacji kopii zapasowych pomaga ograniczyć zależność od jednego zadania.
Sprawdź, czy niedobór pamięci nie uszkodził Dockera
W wątku opisano, że długotrwała presja na pamięć ostatecznie uniemożliwiła dostęp do aplikacji Dockera. Po ustabilizowaniu hosta sprawdź docker ps, demona Dockera i najważniejsze kontenery, zanim ponownie uruchomisz duże zadanie tworzenia kopii zapasowej.
Po aktualizacji rozpocznij od małej kopii zapasowej
Nie uruchamiaj od razu wieloterabajtowego zadania ani zadania na USB, które wywołało awarię. Utwórz małe zadanie testowe, monitoruj pamięć przez 10–20 minut, a następnie stopniowo zwiększaj liczbę plików i ich łączny rozmiar. Ułatwi to sprawdzenie, czy poprawiona usługa utrzymuje stabilne zużycie zasobów.
Liczba plików jest równie ważna jak liczba bajtów
Setki tysięcy małych plików mogą wymagać znacznie więcej pracy związanej z metadanymi niż kilka dużych plików multimedialnych. W zgłoszeniu do pomocy technicznej podaj zarówno łączny rozmiar danych, jak i przybliżoną liczbę plików.
Podczas testów utrzymuj niezależną ścieżkę kopii zapasowych
Jeśli wbudowana funkcja Backup była wcześniej niekompletna lub niestabilna, utrzymuj inną, sprawdzoną kopię za pomocą osobnego narzędzia lub w innej lokalizacji, dopóki test przywracania nie potwierdzi, że bieżące zadanie ZimaOS jest godne zaufania.
Zachowaj dzienniki sprzed i po poprawce
Przed aktualizacją zapisz komunikaty OOM, procesy o największym zużyciu pamięci, wersję ZimaOS i typ miejsca docelowego kopii zapasowej. Następnie po aktualizacji do wersji 1.7.1 lub nowszej powtórz ten sam kontrolowany scenariusz i porównaj wzrost zużycia pamięci. Dzięki temu uzyskasz dowody usunięcia regresji, zamiast polegać wyłącznie na tym, że „serwer wydaje się stabilny”.
Jeśli w poprawionej wersji zużycie pamięci nadal rośnie bez ograniczeń, zatrzymaj zadanie i przekaż pomocy technicznej pomiary wykonane przed i po aktualizacji.
Najczęściej zadawane pytania
Czy wyciek pamięci został potwierdzony przez wielu użytkowników?
Tak. Kilku użytkowników zgłosiło takie samo zachowanie w wersji 1.7.0.
Czy wersja 1.7.1 rozwiązała tę klasę problemów?
Tak. Oficjalny dziennik zmian zawiera poprawki pamięci i kopii zapasowych, które bezpośrednio dotyczą tego problemu.
Czy powinienem wrócić do wersji 1.6.2?
Było to tymczasowe obejście stosowane przed wydaniem wersji 1.7.1. Obecni użytkownicy powinni wybrać poprawioną stabilną wersję.
Skąd mam wiedzieć, że poprawka zadziałała?
Uruchom kontrolowaną kopię zapasową i monitoruj pamięć, pamięć wymiany, dzienniki oraz kompletność danych w miejscu docelowym.
