Co powoduje spowolnienie wyszukiwania lub wyników zapytań w Immich w miarę wzrostu ilości danych?

Wyszukiwanie w Immich zwalnia wraz ze wzrostem biblioteki, gdy większe indeksy i zbiory robocze przekraczają możliwości wydajnej pamięci podręcznej, filtrowania lub magazynu — nie po prostu dlatego, że istnieją zdjęcia.

Większa biblioteka zwiększa jednocześnie kilka wartości: liczbę wierszy, embeddingów, metadanych, miniatur oraz możliwych kombinacji filtrów. Zdiagnozuj etap, który zwalnia, ponieważ szybszy magazyn plików nie naprawi nieefektywnej ścieżki zapytania, a dostrajanie bazy danych nie przyspieszy zdalnego montowania miniatur.

Rozrost obejmuje więcej niż pierwotną bibliotekę

Każdy dodany zasób może zwiększać liczbę wierszy bazy danych, wyodrębnionych metadanych, reprezentacji wyszukiwania, twarzy, miniatur i zakodowanych multimediów. Struktury te rosną w różnym tempie i są używane w różny sposób. Terabajty pierwotnej biblioteki nie pozwalają więc przewidzieć czasu wyszukiwania bez wiedzy o liczbie przeszukiwalnych elementów i obiektów pochodnych, przez które przechodzi żądanie.

Analiza ścieżki danych Immich firmy ZimaSpace rozdziela przetwarzanie w tle, przeszukiwalne reprezentacje, wybór danych w bazie oraz dostarczane multimedia. Jej praktyczny wniosek dotyczący diagnozowania zapytań jest taki, że rozrost biblioteki zmienia zarówno przeszukiwalny katalog, jak i pliki prezentowane po uzyskaniu wyniku, tworząc więcej niż jedno potencjalne źródło opóźnień.

Na każdym etapie zapisuj liczbę zasobów, rozmiar bazy danych, rozmiar indeksu wektorowego, zajętość miniatur oraz liczność często używanych filtrów. Szereg czasowy pokazuje, która struktura rośnie wraz z opóźnieniem, i zapobiega obwinianiu niezwiązanego ze sprawą wzrostu liczby bajtów oryginalnych nagrań za czas wyboru danych w bazie.

Indeksy wektorowe stają się wrażliwe na dopasowanie do pamięci

Wyszukiwanie semantyczne przechodzi przez indeks reprezentacji zamiast odczytywać każdy oryginalny obraz. W miarę jego wzrostu aktywny graf lub strony mogą przestać mieścić się w pamięci. Losowe chybienia pamięci podręcznej zamieniają wtedy operacje wykonywane z prędkością pamięci na odczyty z magazynu, przez co opóźnienie ogona rośnie gwałtowniej, niż sugerowałoby średnie wykorzystanie procesora.

Analiza inżynieryjna wyszukiwania wektorowego w PostgreSQL wyjaśnia, że wydajność HNSW może się pogorszyć, gdy aktywny graf przerośnie pamięć, ponieważ przechodzenie z losowym dostępem staje się wrażliwe na chybienia pamięci podręcznej. Wersje Immich i implementacje indeksów mogą się zmieniać, dlatego potraktuj to jako mechanizm do przetestowania, a nie zalecenie konkretnej konfiguracji.

Zmierz czas stałego zapytania semantycznego po ponownym uruchomieniu, po jednym rozgrzaniu oraz po dotknięciu niezwiązanych regionów biblioteki. Porównaj odczyty bazy danych, działanie pamięci podręcznej i opóźnienie urządzenia. Duża poprawa po rozgrzaniu, która znika wraz z poszerzaniem zbioru roboczego, potwierdza hipotezę dotyczącą dopasowania do pamięci; równomiernie wolne zapytania wskazują na inne źródło problemu.

Filtry i plany zapytań mogą się zmieniać wraz z licznością danych

Data, osoba, właściciel, album i inne warunki zmieniają liczbę kandydatów pozostających przed rankingiem lub w jego trakcie. Wraz ze zmianą rozkładu danych ten sam widoczny filtr może wybierać znacznie większą część biblioteki. Statystyki bazy danych i wybór planu mogą więc mieć znaczenie, nawet gdy samo wyszukiwane hasło pozostaje niezmienione.

Przegląd ograniczeń pgvector wskazuje, że łączenie wyszukiwania wektorowego z filtrami metadanych może być trudne, a obciążenia wektorowe współdzielą procesor, pamięć i operacje wejścia-wyjścia PostgreSQL z pracą transakcyjną. Artykuł przedstawia ogólne informacje o PostgreSQL, więc potwierdza mechanizm, ale nie dowodzi istnienia konkretnego planu zapytania Immich.

Przygotuj pary wyszukiwań — z jednym filtrem i bez niego — korzystając ze znanych zbiorów wyników. Rejestruj czas zapytań po stronie serwera i aktywność bazy danych, a nie tylko zakończenie operacji w przeglądarce. Jeśli czas wyboru danych rośnie, a zwracanie miniatur pozostaje szybkie, skup się na planach, statystykach, dopasowaniu indeksu i rywalizacji o zasoby zamiast na magazynie multimediów.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Oddziel wybór wyników od renderowania wyników

Interfejs może wydawać się powolny, mimo że baza danych wybrała już identyfikatory pasujących zasobów. Renderowanie nadal wymaga wyszukania miniatur, odczytów z magazynu, przesłania odpowiedzi i dekodowania po stronie klienta. Rozrastające się drzewo obiektów pochodnych lub zdalnie zamontowany magazyn może opóźnić tę drugą fazę, podczas gdy samo zapytanie wyszukiwania pozostaje sprawne.

Raport dotyczący dużego importu opisuje ogólną powolność Immich, gdy w kolejce pozostawały setki tysięcy zadań związanych z metadanymi i miniaturami. Pokazuje to nakładające się obciążenie w tle, a nie uniwersalne ograniczenie skalowania, i wyjaśnia, dlaczego testy wzrostu należy przeprowadzać zarówno przy aktywnych kolejkach, jak i po ich opróżnieniu.

Za pomocą pomiarów przeglądarki lub obserwacji interfejsu API zaznacz osobno zakończenie odpowiedzi z wynikami i moment wyświetlenia ostatniej widocznej miniatury. Powtórz znane wyszukiwanie przy wstrzymanych kolejkach, a następnie przy aktywnych. Jeśli zwalnia pobieranie identyfikatorów, zbadaj ścieżki bazy danych i indeksu; jeśli wolniejsze są tylko obrazy, sprawdź magazyn miniatur, dostarczanie przez sieć, dekodowanie po stronie klienta i konkurencyjne operacje wejścia-wyjścia w tle.