Jak Immich planuje indeksowanie wyszukiwania podczas importowania dużych bibliotek mobilnych

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.

Podczas dużego importu biblioteki mobilnej Immich może przyjmować zasoby szybciej, niż wszystkie zadania w tle związane z wyszukiwaniem zdążą się zakończyć, dlatego aktualność wyszukiwania może być opóźniona względem ukończenia przesyłania.

Takie opóźnienie jest problemem harmonogramowania tylko wtedy, gdy wymagane zadania oczekują, są wykonywane lub konkurują o współdzielone zasoby; samo w sobie nie oznacza awarii wyszukiwania. Przydatny jest model potoku: przychodzące zasoby tworzą zadania, kolejki pochłaniają nagłe wzrosty obciążenia, pracownicy opróżniają te kolejki, a baza danych otrzymuje wyniki, od których zależą późniejsze wyszukiwania.

Duże importy tworzą serię różnych zadań

Migracja mobilna to coś więcej niż kopiowanie bajtów. Każdy zaakceptowany zasób może utworzyć dodatkowe zadania związane z miniaturami, metadanymi, obsługą wideo, inteligentnym wyszukiwaniem, rozpoznawaniem twarzy lub innymi włączonymi funkcjami. Ponieważ zadania te mają różne koszty i zależności, jeden import może utworzyć kilka zaległości o różnym tempie opróżniania.

Prośba o zadania sekwencyjne pokazuje, dlaczego użytkownicy zauważają to zachowanie na ograniczonych sprzętowo hostach: administratorzy czasami chcą, aby obciążające operacje wykonywały się jedna po drugiej, zamiast nakładać się na siebie. Prośba ta świadczy o konkurencji o zasoby, a nie dowodzi, że wykonywanie sekwencyjne jest najlepsze dla każdego serwera.

Mierz każdą kolejkę na podstawie liczby przychodzących, ukończonych i zakończonych niepowodzeniem zadań, zamiast traktować łączną liczbę oczekujących zadań jako jedno obciążenie. Duża zaległość miniaturek może opóźniać inne zależne zadania inaczej niż zaległość transkodowania wideo, a kolejka, która stale się zmniejsza, ma inne znaczenie niż taka, która wielokrotnie ponawia te same elementy.

Priorytet kolejki to nie to samo co globalne zarządzanie zasobami

System może nadawać priorytet wybranym zadaniom lub je wstrzymywać, a mimo to inne typy zadań mogą nadal być aktywne. Dlatego narzędzie importu, które ogranicza jedną klasę zadań w tle, nie musi gwarantować bezczynności procesora, nieobciążonych dysków ani natychmiastowej aktualności wyszukiwania. Zasady harmonogramowania i całkowite zużycie zasobów są ze sobą powiązane, ale nie są tym samym.

Wydanie immich-go wprowadziło funkcję wstrzymywania zadań w tle podczas przesyłania, aby ograniczyć konflikty. To zachowanie dotyczy tego importera i tej wersji, dlatego nie należy na tej podstawie twierdzić, że każdy mobilny import w Immich automatycznie wstrzymuje te same zadania.

Praktyczną granicą jest obserwowalny postęp. Jeśli przesyłanie trwa szybko, a kolejki związane z wyszukiwaniem są celowo wstrzymane, nowe zasoby będą naturalnie dostępne w wyszukiwaniu później. Jeśli kolejka jest włączona, ale liczba ukończonych zadań pozostaje bliska zeru, pytanie dotyczy już nie zasad harmonogramowania, lecz awarii pracownika, zasobów albo konkretnego zasobu.

Współbieżność może zwiększać przepustowość i pogarszać responsywność

Większa liczba współbieżnych pracowników może zwiększać liczbę ukończonych zadań na minutę, dopóki nie zostanie nasycona współdzielona zależność. Po przekroczeniu tego punktu dodatkowe przetwarzanie równoległe może zwiększać oczekiwanie na bazę danych, opóźnienia pamięci masowej, presję na pamięć lub przełączanie kontekstu. W rezultacie system może średnio szybciej kończyć zadania w tle, a jednocześnie żądania interaktywne mogą charakteryzować się większymi opóźnieniami skrajnymi.

Raport użytkownika dotyczący zawieszonych kolejek zadań opisuje dużą bibliotekę, w której zmniejszenie współbieżności poprawiło obserwowany postęp. Jest to obserwacja zależna od konkretnego wdrożenia, ale pokazuje, dlaczego współbieżność należy testować jako zmienną obciążenia, a nie traktować jej jako stałego wskaźnika możliwości serwera.

Użyj znanego wyszukiwania już zindeksowanego albumu jako kontroli interaktywnej. Jeśli to zapytanie pozostaje szybkie, a zakres nowych zdjęć pozostaje nieaktualny, import jest głównie problemem aktualności. Jeśli jednocześnie spowalniają nawet stare zapytania, a rośnie oczekiwanie na procesor, pamięć masową lub bazę danych, okno harmonogramowania zużywa zapas zasobów potrzebny do obsługi interaktywnej.

-15% OFF

Rosnąca kolejka nie musi oznaczać awarii

Zaległość rośnie zawsze wtedy, gdy zadania napływają szybciej, niż pracownicy je kończą. Podczas celowego importu historycznego jest to przez pewien czas oczekiwane. Sygnałem awarii nie jest sama szczytowa długość kolejki, lecz połączenie zatrzymania postępu, powtarzających się błędów lub zaległości, która nie zmniejsza się po zatrzymaniu napływu zadań.

Dyskusje dotyczące dużych importów, takie jak ta o migracji 200 000 zdjęć, pokazują, jak administratorzy rozdzielają przepustowość przesyłania od przetwarzania następującego po nim. Doświadczenia społeczności są przydatne przy ustalaniu, co mierzyć, ale nie należy zamieniać ich w uniwersalne oszacowanie czasu dla innej biblioteki.

Ten mechanizm przestaje wyjaśniać brak wyników wyszukiwania, gdy odpowiednie zadanie zostało ukończone, a ten sam uprawniony użytkownik nadal nie może pobrać znanego zasobu. W takim przypadku sprawdź trafność zapytania, filtry, uprawnienia, działanie modelu lub przetwarzanie konkretnego zasobu, zamiast dalej dostrajać współbieżność importu.

Przeprowadź test harmonogramowania na dwóch torach

Utwórz jeden stały tor dla starej, zindeksowanej zawartości oraz drugi dla małego nowego importu. Przed rozpoczęciem importu zapisz czas odpowiedzi znanego starego wyszukiwania. W trakcie importu regularnie rejestruj to samo wyszukiwanie, szybkość przesyłania, liczbę oczekujących i ukończonych zadań, błędy, obciążenie procesora, obciążenie pamięci oraz opóźnienia pamięci masowej.

Skorzystaj z analizy ZimaSpace dotyczącej ścieżki danych Immich, aby rozdzielić etapy przesyłania, przetwarzania, przechowywania i wyszukiwania. Wąskie gardło można skutecznie usunąć tylko wtedy, gdy odpowiada etapowi, na którym rzeczywiście nie jest osiągany wymagany poziom obsługi.

Uznaj harmonogram za odpowiedni, jeśli stare wyszukiwania mieszczą się w granicach akceptowanych w domu, kolejki nowych elementów nadal są opróżniane, a zaległość znika po zatrzymaniu napływu zadań. Ogranicz lub przełóż wykonywanie zadań w tle tylko wtedy, gdy kontrolowany test pokaże, że ten sam współdzielony zasób opóźnia zarówno korzystanie interaktywne, jak i postęp kolejki.

Centrum Technologii i Sztucznej Inteligencji

Więcej do przeczytania

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.