Dlaczego Immich powoduje powtarzającą się aktywność dysku w nocy?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Why Does Immich Cause Repeated Disk Activity Overnight? - Zima Store Online

Immich może generować powtarzającą się aktywność dysku w nocy, ponieważ zaplanowana konserwacja, operacje na bazie danych, zadania multimedialne w kolejce lub ponowne próby są kontynuowane po zakończeniu korzystania z biblioteki.

Cichy dom nie oznacza bezczynnego serwera. Istotne pytanie brzmi, czy ten sam proces i zadanie wyjaśniają odczyty lub zapisy występujące o tej samej porze. Najpierw skoreluj aktywność, a dopiero potem zdecyduj, czy jest to oczekiwana praca, nadrabianie zaległości czy pętla, którą należy zatrzymać.

Najpierw dopasuj skok aktywności dysku do godziny

Zacznij od trzech nocy z zapisanymi znacznikami czasu, zamiast opierać się na jednej chaotycznej obserwacji. Zapisz, kiedy rośnie wejście/wyjście blokowe, które urządzenie jest obciążone, czy dominują odczyty, czy zapisy oraz czy wzorzec zaczyna się niemal o tej samej porze. Powtarzalna godzina rozpoczęcia wskazuje na harmonogram; nieregularny wzorzec silniej sugeruje napływające zadania, ponowne próby lub inny kontener.

Wdrożenia Immich mogą planować kopie zapasowe bazy danych i prace związane z kontrolą integralności w godzinach małego obciążenia, więc skok nad ranem może być zamierzony. Nie wyłączaj zadania tylko dlatego, że uruchamia dyski. Najpierw sprawdź, czy po okresie aktywności pojawia się odpowiednia kopia zapasowa, wynik konserwacji lub zakończenie pracy kolejki.

Powiązana diagnoza ZimaSpace dotycząca pracy Immich w tle podczas bezczynności stosuje tę samą zasadę analizy czasu: połącz widoczny objaw z procesem i zadaniem, zanim uznasz „bezczynność” za stan awarii.

Oddziel zapisy PostgreSQL od odczytów multimediów

Zmiany stanu aplikacji Immich mogą utrzymywać aktywność PostgreSQL nawet wtedy, gdy nie jest otwierane żadne nowe zdjęcie. Punkty kontrolne bazy danych, rejestrowanie z wyprzedzeniem, operacje związane z vacuum oraz zwykłe aktualizacje aplikacji mają inny profil wejścia/wyjścia niż skanowanie tysięcy plików multimedialnych. Zidentyfikuj ścieżkę lub urządzenie odbierające ruch, zanim obwinisz bibliotekę zdjęć.

Omówienie obserwowalności PostgreSQL w artykule analiza pg_stat_io wyjaśnia, dlaczego należy oddzielić odczyty, zapisy, aktywność procesów zaplecza, działanie procesu punktów kontrolnych i zapisy w tle. Wykorzystaj to rozróżnienie, aby ustalić, czy urządzenie bazy danych jest zajęte, ponieważ zapisywane są użyteczne transakcje, czy dlatego, że coś stale generuje zbędny ruch.

Jeśli zapisy bazy danych są małe i okresowe, a dyski z multimediami pozostają uśpione, zachowanie może być normalną konserwacją bazy danych. Jeśli ten sam plik bazy danych otrzymuje ciągłe, intensywne zapisy, podczas gdy żadne zadanie nie posuwa się naprzód, zachowaj logi i sprawdź odpowiedzialne zapytania lub pętlę ponownego uruchamiania, zamiast przenosić całą bibliotekę na szybszą pamięć masową.

Sprawdź, czy kolejki zadań w tle rzeczywiście posuwają się naprzód

Otwórz widok zadań i porównaj liczbę zadań oczekujących, aktywnych, zakończonych niepowodzeniem i ukończonych przed nocnym okresem pracy oraz po nim. Generowanie miniatur, przetwarzanie wideo, wyodrębnianie metadanych, zadania uczenia maszynowego lub praca nad zaimportowaną biblioteką mogą zasadnie utrzymywać aktywność pamięci masowej po dużej zmianie. Zmniejszająca się liczba zaległości świadczy o pożytecznym nadrabianiu zaległości.

Aktualny raport społeczności dotyczący utrzymujących się, niewyjaśnionych odczytów pokazuje przeciwną granicę diagnostyczną: bardzo wysokie, ciągłe odczyty bez oczekiwanej pracy wymagają zbadania, a nie uznania ich za „typowe działanie Immich”. Traktuj podaną szybkość jako przypadek, nie punkt odniesienia.

Jeśli te same zadania wielokrotnie kończą się niepowodzeniem i wracają do kolejki, aktywność dysku może się powtarzać bez postępów. Zapisz pierwszy błąd i jeden zasób, którego dotyczy, a następnie odizoluj ten typ zadania. Nie czyść wszystkich kolejek ani nie generuj ponownie całej biblioteki, zanim nie ustalisz, czy pętla jest spowodowana jednym plikiem, uprawnieniami, opóźnieniami pamięci masowej lub zależnością usługi.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Przypisz wejście/wyjście do procesu zamiast zgadywać na podstawie hałasu dysku

Podczas kolejnego wystąpienia użyj monitorowania wejścia/wyjścia na poziomie hosta, aby zidentyfikować proces odczytujący dane z urządzenia lub zapisujący je na nim. Następnie przypisz ten proces do serwera Immich, PostgreSQL, uczenia maszynowego, narzędzia do tworzenia kopii zapasowych, programu antywirusowego, sprawdzania systemu plików lub niezwiązanego kontenera. Diody dysku i hałas wentylatorów nie dostarczają informacji o właścicielu aktywności.

Praktyczny przebieg pracy z iotop pokazuje metodę skoncentrowaną na procesie. Zapisz kilka próbek, ponieważ krótki zryw może zniknąć między obserwacjami; celem jest uchwycenie procesu w tym samym czasie, gdy występuje objaw.

Jeśli Immich nie jest głównym użytkownikiem wejścia/wyjścia, przestań zmieniać ustawienia Immich i zajmij się rzeczywistym procesem. Jeśli odpowiada za to PostgreSQL, Immich lub powiązany proces roboczy, porównaj jego logi i postępy zadań z próbką wejścia/wyjścia. Dzięki temu „serwer hałasuje każdej nocy” staje się konkretnym komponentem i wyzwalaczem.

Wyznacz granicę między normalną pracą nocną a usterką

Uznaj aktywność za normalną, jeśli rozpoczyna się zgodnie ze znanym harmonogramem lub po niedawnej zmianie biblioteki, wykonuje użyteczną pracę, nie powoduje narastania liczby błędów, a opóźnienia pamięci masowej i głębokość kolejki wracają do wartości bazowych. Zapisz normalny czas trwania, aby przyszły wzrost mieć z czym porównać.

Historyczna dyskusja użytkowników Immich na temat częstych zapisów bazy danych pokazuje, dlaczego pewna aktywność bazy danych może występować bez widocznego działania użytkownika. Ponieważ wersje i wdrożenia się zmieniają, wykorzystaj ten przypadek jedynie jako uzasadnienie osobnego pomiaru bazy danych, a nie jako dowód, że każdy trwały zapis jest normalny.

Eskaluje problem, gdy wejście/wyjście trwa po zatrzymaniu kolejek, te same błędy powtarzają się, opóźnienia pamięci masowej wpływają na korzystanie w ciągu dnia, ilość wolnego miejsca nieoczekiwanie spada lub wzorzec nasila się z każdą nocą. Zanim wprowadzisz inwazyjne zmiany, zachowaj znaczniki czasu, informacje o wejściu/wyjściu procesów, liczbę zadań, odpowiednie logi, ilość wolnego miejsca w systemie plików oraz jeden powtarzalny wyzwalacz.