Dlaczego Immich ponownie przetwarza istniejące dane po aktualizacji?

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 Reprocess Existing Data After an Upgrade?

Immich może ponownie przetwarzać istniejące zasoby, gdy aktualizacja zmienia kod, modele, metadane lub reguły pochodne definiujące bieżący wynik.

Oryginalne zdjęcia się nie zmieniły, jednak miniatury, wektory reprezentacji, twarze, podglądy lub rekordy w bazie danych mogą już nie spełniać wymagań nowej wersji. Poniżej przedstawiono zwięzłe wyjaśnienie, który wynik został unieważniony, która kolejka go regeneruje oraz czy praca kończy się jednokrotnie, czy powtarza się nieprawidłowo.

Aktualizacja może zmienić to, co uznaje się za bieżący wynik

Wygenerowane dane są prawidłowe względem kodu, modelu, ustawień i schematu, które je utworzyły. Gdy te założenia się zmienią, istniejąca miniatura, wektor reprezentacji, wynik rozpoznawania twarzy lub rekord metadanych może przestać być uznawany za aktualny. Zasób nadal pozostaje danymi wejściowymi, mimo że pracy wymaga tylko jego reprezentacja pochodna.

Artykuł ZimaSpace dotyczący kopii zapasowych w Immich rozróżnia niezbędne oryginały i stan bazy danych od pochodnych danych, które można wygenerować ponownie. To rozróżnienie wyjaśnia, dlaczego prace związane z aktualizacją mogą być zakrojone na dużą skalę, nie oznaczając duplikowania oryginalnych plików: aplikacja może odbudowywać stan pochodny wokół niezmienionych multimediów.

Zapisz, które kolejki rosną bezpośrednio po aktualizacji oraz które katalogi lub rozmiary baz danych się zmieniają. Kolejka miniatur, kolejka uczenia maszynowego i migracja bazy danych oznaczają różne mechanizmy. Nazywanie ich wszystkich „indeksowaniem” usuwa dowody potrzebne do oszacowania czasu trwania i obciążenia zasobów.

Zmiany zależności i modeli mogą unieważnić wcześniejsze wyniki

Immich obejmuje kod aplikacji, działanie bazy danych, koordynację kolejek, modele uczenia maszynowego i pochodne dane multimedialne. Aktualizacja może zmienić interfejsy lub oczekiwany sposób przechowywania danych między tymi komponentami. Migracja może szybko zaktualizować rekordy, podczas gdy działające w tle procesy robocze później ponownie wygenerują kosztowne wyniki dla każdego dotkniętego zasobu.

Dyskusja społeczności na temat przygotowań do Immich v3 podkreśla niepewność dotyczącą PostgreSQL, Redis, rozszerzeń wektorowych i wersji aplikacji. Dyskusja nie dowodzi, że należy wykonać konkretne działanie aktualizacyjne, ale pokazuje, że zgodność zależności jest częścią zmiany stanu, a nie niezwiązanym szczegółem konserwacji.

Zachowaj wersje komponentów sprzed aktualizacji oraz zrzut stanu kolejek po aktualizacji. Jeśli zaplanowana zostanie tylko jedna klasa wyników i proces zakończy się jednokrotnie, zachowanie odpowiada ograniczonej regeneracji. Jeśli komponenty nie zgadzają się co do schematu lub rozszerzeń, mogą pojawić się powtarzające się błędy, zanim w ogóle rozpocznie się użyteczne ponowne przetwarzanie.

Ponowne przetwarzanie zamienia prace związane ze zgodnością w obciążenie zasobów

Duża biblioteka może zamienić jedną zmienioną regułę w tysiące zadań. Generowanie miniatur i analiza multimediów zużywają procesor lub akceleratory, a odczytywanie oryginałów i zapisywanie danych pochodnych zużywają przepustowość pamięci masowej. Aktualizacje bazy danych i aktywność kolejek trwają jednocześnie, więc przeglądanie biblioteki może zwolnić, nawet gdy ponowne przetwarzanie przebiega prawidłowo.

Wątek pomocy technicznej Immich opisuje wysokie nocne użycie procesora i ponowne generowanie miniatur po aktualizacji na dwóch serwerach. To raport z praktyki, a nie dowód zamierzonego działania, ale dostarcza dokładnego wzorca obserwacji, który należy porównać z postępem kolejki, logami i powtarzalnością zakończenia procesu.

Śledź liczbę ukończonych elementów na minutę, wolne miejsce w pamięci masowej, opóźnienia urządzeń, presję pamięci oraz stałe interaktywne żądanie. Prawidłowe ponowne przetwarzanie powinno zmniejszać skończony zaległy backlog. Ograniczenie współbieżności może chronić codzienne korzystanie z biblioteki kosztem czasu trwania; dodanie procesów roboczych może pogorszyć rywalizację o pamięć masową lub bazę danych, gdy te etapy już wyznaczają limit.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Rozróżnij jednorazową regenerację od powtarzającej się awarii

Przed aktualizacją zapisz liczbę zadań, wersje, ilość wolnego miejsca oraz identyfikatory kilku znanych zasobów. Po aktualizacji sprawdzaj te same identyfikatory i zapisuj, który wynik jest odbudowywany, czy liczby w kolejkach maleją oraz czy praca powraca po ponownym uruchomieniu lub podczas kolejnego zaplanowanego okna konserwacji.

Dyskusja dotycząca odzyskiwania miniatur opisuje przypadki, w których brakujące obrazy pojawiły się po zakończeniu przetwarzania, podczas gdy ręczne odświeżenie pomogło w przypadku niektórych pojedynczych zasobów. Te mieszane relacje wzmacniają rozróżnienie: sam upływ czasu nie pozwala sklasyfikować zachowania; skończony postęp kolejki różni się od sytuacji, w której te same zasoby wielokrotnie kończą się błędem lub są ponownie dodawane do kolejki.

Traktuj stale malejące kolejki i stabilne wyniki jako jednorazową regenerację. Podejmij dalsze działania, gdy liczby ukończonych zadań się zerują, powracają identyczne zasoby, błędy się powtarzają, wolne miejsce gwałtownie maleje lub nie pojawia się żadna użyteczna przepustowość. Przed zmianą stanu zadań zachowaj kopie zapasowe i logi, ponieważ usunięcie dowodów może utrudnić ustalenie, czy pętlę wywołała aktualizacja, czy środowisko.