Dlaczego po zmianie biblioteki gwałtownie wzrasta obciążenie związane z działaniem Immich w tle?

Praca w tle Immich może gwałtownie wzrosnąć po zmianie biblioteki, ponieważ jedno zdarzenie dotyczące systemu plików lub biblioteki może wygenerować skanowanie, zadania metadanych, tworzenie plików pochodnych i indeksowanie.

Ważne jest rozróżnienie między ograniczoną falą oczekiwanego ponownego przetwarzania a pracą, która wielokrotnie obejmuje te same zasoby bez odpowiadającej jej zmiany. Przeniesienie folderu, ponowne skanowanie biblioteki zewnętrznej, nowo wykryte pliki lub zachowanie zależne od wersji mogą generować podobne wykresy użycia procesora i kolejek, dlatego zdarzenie biblioteki trzeba powiązać z dokładnymi zadaniami, które utworzyło.

Skanowanie biblioteki to etap wykrywania, a nie całe obciążenie

Skanowanie najpierw uzgadnia to, co Immich widzi na dysku, z tym, co już wie o bibliotece. Wykrycie nowego lub zmienionego zasobu może następnie sprawić, że dane wyjściowe dalszych etapów będą nieaktualne lub brakujące, co utworzy dodatkową pracę po zakończeniu samego skanowania.

Raport użytkownika dotyczący nakładających się skanów bibliotek opisuje sytuację, w której kolejka skanowania została opróżniona, podczas gdy kolejki miniaturek, rozpoznawania twarzy i innych zadań pozostały mocno zapełnione. Kluczowym mechanizmem jest rozgałęzianie zadań: krótki etap wykrywania może utworzyć znacznie dłuższy ogon przetwarzania.

Odczytuj kolejki w kolejności zależności. Jeśli kolejka biblioteki spada do zera, a kolejki zadań pochodnych nadal się opróżniają, serwer może po prostu przetwarzać zadania utworzone przez zakończone skanowanie. Nazywanie całego tego okresu powtarzającym się skanowaniem zaciemnia informację o tym, który etap faktycznie zużywa zasoby.

Zmiany ścieżek mogą wyglądać jak przetwarzanie nowych zasobów

Biblioteki zewnętrzne są szczególnie wrażliwe na tożsamość systemu plików i zmiany ścieżek. Gdy pliki są reorganizowane, aplikacja może uzgadniać ich nowe lokalizacje z zapisanym stanem zasobów. W zależności od zachowania danej wersji i typu biblioteki może to uruchomić więcej pracy, niż sugerowałaby liczba naprawdę nowych zdjęć.

W dyskusji z 2026 roku dotyczącej przeniesionych plików zewnętrznych opisano przypadek, w którym zreorganizowane ścieżki potraktowano jako nowe zasoby, co doprowadziło do ponownego tworzenia miniaturek, analizy ML i przetwarzania wideo. To raport o znanym ograniczeniu, a nie gwarancja, że każde przeniesienie folderu będzie zachowywać się identycznie.

Wyjaśnia to, dlaczego reorganizacja biblioteki może być znacznie bardziej kosztowna niż dodanie takiej samej liczby nowych zdjęć. Jeśli jednak ścieżki plików i ich zawartość się nie zmieniły, powtarzające się pełne generowanie wskazuje na inny problem i należy go zbadać, zamiast uznawać za normalne zachowanie w tle.

Kolejki dalszych etapów mogą rosnąć, nawet gdy praca jest wykonywana

Liczba oczekujących zadań nie musi maleć monotonicznie. Po zakończeniu jednego zadania zasób może kwalifikować się do kolejnego zadania albo mogą zostać dodane następne zadania do późniejszego etapu. Podczas dużego uzgadniania serwer może więc jednocześnie wykazywać aktywny postęp i rosnącą kolejkę dalszego etapu.

Dyskusja dotycząca zaległości miniaturek wskazuje, że nowe zadania tworzenia miniaturek mogą pojawiać się w miarę kończenia innego przetwarzania. Pokazuje też istotną granicę: historyczne błędy i nieprawidłowo skonfigurowane ścieżki importu mogą tworzyć patologiczne pętle, dlatego rosnącą kolejkę należy interpretować w kontekście wersji i ścieżek.

Korzystaj z liczników ukończonej pracy i wyrywkowo sprawdzaj najnowsze wyniki, a nie tylko liczbę oczekujących zadań. Jeśli miniaturki się pojawiają, liczba ukończeń rośnie, a tempo z czasem przewyższa liczbę nowych zadań, kolejka się opróżnia, nawet jeśli jej szczyt nastąpi po zakończeniu pierwotnego skanowania biblioteki.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Skok obciążenia jest nietypowy, gdy pracy nie odpowiada żadna zmiana

Oczekiwane obciążenie w tle powinno dać się przypisać określonemu zdarzeniu: nowym zasobom, odświeżeniu metadanych, zmianie ścieżki, zmianie modelu lub jawnie uruchomionej regeneracji. Wyjaśnienie traci wiarygodność, gdy te same stare zasoby są wielokrotnie planowane bez zmiany konfiguracji ani zawartości.

Niedawny raport, w którym jedno skanowanie wpłynęło na inne biblioteki, pozornie prowadząc do ponownego generowania zadań w wielu bibliotekach zewnętrznych, pokazuje, dlaczego zakres ma znaczenie. Traktuj takie raporty jako dowody ograniczone do określonej wersji i porównuj je z własnymi logami, zamiast uznawać je za standardowe zachowanie Immich.

Ten mechanizm przestaje również wyjaśniać sytuację, w której host pozostaje zajęty długo po opróżnieniu odpowiednich kolejek. W takim przypadku sprawdź konserwację bazy danych, kopie zapasowe, inny kontener, aktywność systemu plików lub zawieszony proces. Zmiana biblioteki nie powinna stać się uniwersalnym wyjaśnieniem każdego długotrwałego obciążenia.

Powiąż zmianę z mapą zadań przed i po jej wykonaniu

Przed kontrolowaną zmianą biblioteki zapisz liczbę zasobów, liczbę oczekujących i aktywnych zadań dla głównych procesów, użycie procesora, opóźnienie pamięci masowej oraz czas ostatniego zakończonego skanowania. Dodaj lub przenieś niewielką, znaną grupę zasobów, wykonaj tę samą obserwację ponownie i odnotuj dokładnie, które kolejki rosną oraz jak szybko się opróżniają.

Skorzystaj z wyjaśnienia ścieżki danych Immich firmy ZimaSpace, aby przypisać każdy skok do wykrywania, przetwarzania, bazy danych lub pamięci masowej, zamiast traktować całą aktywność w tle jako jedną kategorię.

Zaakceptuj skok obciążenia, gdy wygenerowana praca jest proporcjonalna do kontrolowanej zmiany, pojawiają się wyniki, liczba błędów pozostaje ograniczona, a kolejki wracają w kierunku poziomu bazowego. Podejmij dalsze działania, gdy niezmienione zasoby są wielokrotnie regenerowane, zakres wykracza poza zmienioną bibliotekę lub te same zadania kończą się błędami bez postępu.