Was verlangsamt die Immich-Suche oder die Abfrageergebnisse, wenn die Datenmenge wächst?

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

What Causes Immich Search or Query Results to Slow as Data Grows?

Die Immich-Suche wird bei wachsendem Umfang langsamer, wenn größere Indizes und Arbeitssätze den effizienten Cache-, Filter- oder Speichernutzungsbereich überschreiten – nicht einfach nur, weil Fotos vorhanden sind.

Eine größere Bibliothek erhöht mehrere Größen gleichzeitig: Zeilen, Embeddings, Metadaten, Vorschaubilder und mögliche Filterkombinationen. Ermitteln Sie, welche Phase langsamer wird, denn schnellerer Dateispeicher kann keinen schlechten Abfragepfad beheben, während Datenbank-Tuning ein entfernt eingebundenes Thumbnail-Verzeichnis nicht beschleunigen kann.

Das Wachstum erweitert mehr als nur die ursprüngliche Bibliothek

Jedes hinzugefügte Asset kann Datenbankzeilen, extrahierte Metadaten, Suchrepräsentationen, Gesichter, Vorschaubilder und codierte Medien hinzufügen. Diese Strukturen wachsen unterschiedlich schnell und werden auf unterschiedliche Weise abgerufen. Terabytes der ursprünglichen Bibliothek können die Suchlatenz daher nicht vorhersagen, ohne zu wissen, wie viele durchsuchbare Entitäten und abgeleitete Objekte die Anfrage durchläuft.

Die Analyse des Immich-Datenpfads von ZimaSpace unterscheidet zwischen Hintergrundverarbeitung, durchsuchbaren Repräsentationen, Datenbankauswahl und ausgelieferten Medien. Die praktische Erkenntnis für die Diagnose von Abfragen lautet: Das Wachstum der Bibliothek verändert sowohl den durchsuchbaren Katalog als auch die nach einem Treffer präsentierten Dateien, wodurch mehr als eine potenzielle Verzögerung entsteht.

Erfassen Sie bei jedem Meilenstein die Anzahl der Assets, die Datenbankgröße, die Größe des Vektorindexes, den Umfang der Vorschaubilder und die Kardinalität häufig verwendeter Filter. Eine Zeitreihe zeigt, welche Struktur gemeinsam mit der Latenz wächst, und verhindert, dass ein unabhängiger Anstieg der Größe ursprünglicher Videos für die Dauer der Datenbankauswahl verantwortlich gemacht wird.

Vektorindizes reagieren empfindlich darauf, ob sie in den Arbeitsspeicher passen

Die semantische Suche durchläuft einen Repräsentationsindex, anstatt jedes ursprüngliche Bild zu lesen. Wenn dieser Index wächst, bleiben sein aktiver Graph oder seine Seiten möglicherweise nicht mehr vollständig im Arbeitsspeicher. Zufällige Cache-Fehlzugriffe verwandeln Arbeit mit Arbeitsspeichergeschwindigkeit in Speicherzugriffe, wodurch die Tail-Latenz stärker ansteigt, als die durchschnittliche CPU-Auslastung vermuten lässt.

Eine technische Analyse der Vektorsuche in PostgreSQL erklärt, dass sich die HNSW-Leistung verschlechtern kann, wenn der aktive Graph den Arbeitsspeicher übersteigt, da die Traversierung mit Direktzugriff empfindlich auf Cache-Fehlzugriffe reagiert. Immich-Versionen und Indeximplementierungen können sich ändern. Verwenden Sie dies daher als zu prüfenden Mechanismus und nicht als konkrete Konfigurationsvorgabe.

Messen Sie eine festgelegte semantische Abfrage nach einem Neustart, nach einem Aufwärmdurchlauf und nachdem Sie auf nicht verwandte Bereiche der Bibliothek zugegriffen haben. Vergleichen Sie Datenbankzugriffe, das Cache-Trefferverhalten und die Gerätelatenz. Deutliche Verbesserungen nach dem Aufwärmen, die verschwinden, sobald sich der Arbeitssatz erweitert, stützen die Hypothese eines unzureichenden Speicher-Fits; durchgehend langsame Abfragen weisen auf eine andere Ursache hin.

Filter und Abfragepläne können sich mit der Kardinalität ändern

Datum, Person, Eigentümer, Album und andere Bedingungen verändern, wie viele Kandidaten vor oder während des Rankings übrig bleiben. Wenn sich die Datenverteilung ändert, kann derselbe sichtbare Filter einen deutlich größeren Anteil der Bibliothek auswählen. Datenbankstatistiken und die Wahl des Abfrageplans können daher relevant werden, selbst wenn der Suchbegriff unverändert bleibt.

Eine Übersicht zu den Einschränkungen von pgvector weist darauf hin, dass die Kombination von Vektorsuche und Metadatenfiltern schwierig sein kann und dass Vektor-Workloads CPU, Arbeitsspeicher und I/O von PostgreSQL mit transaktionalen Aufgaben teilen. Der Artikel liefert allgemeine Hinweise zu PostgreSQL und belegt daher den Mechanismus, nicht jedoch einen bestimmten Immich-Abfrageplan.

Erstellen Sie Vergleichssuchen mit und ohne jeweils einen Filter und verwenden Sie bekannte Ergebnismengen. Erfassen Sie die serverseitige Abfragezeit und die Datenbankaktivität, nicht nur den Abschluss im Browser. Wenn die Auswahlzeit wächst, während zurückgegebene Vorschaubilder schnell geladen werden, konzentrieren Sie sich auf Pläne, Statistiken, Index-Fit und Konkurrenz um Ressourcen statt auf den Medienspeicher.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

Trennen Sie die Auswahl der Ergebnisse von ihrer Darstellung

Die Benutzeroberfläche kann sich langsam anfühlen, obwohl die Datenbank bereits die passenden Asset-IDs ausgewählt hat. Für die Darstellung sind weiterhin das Abrufen der Vorschaubilder, Speicherzugriffe, die Übertragung der Antwort und die Dekodierung auf dem Client erforderlich. Ein wachsender Baum abgeleiteter Dateien oder ein entfernt eingebundenes Verzeichnis kann diese zweite Phase verzögern, während die eigentliche Suchabfrage weiterhin problemlos funktioniert.

Ein Bericht über einen großen Import beschreibt eine allgemein langsame Immich-Instanz, während Hunderttausende Metadaten- und Thumbnail-Aufgaben noch in der Warteschlange standen. Er zeigt eine überlappende Hintergrundbelastung, keine allgemeingültige Skalierungsgrenze, und verdeutlicht, warum Wachstumstests sowohl mit aktiven Warteschlangen als auch nach deren Abarbeitung durchgeführt werden sollten.

Markieren Sie mithilfe von Browser-Timing oder API-Beobachtungen den Abschluss der Ergebnisantwort getrennt vom Zeitpunkt, an dem das letzte sichtbare Vorschaubild geladen ist. Wiederholen Sie eine bekannte Suche zunächst bei pausierten und anschließend bei aktiven Warteschlangen. Wenn sich die IDs verzögert liefern, untersuchen Sie Datenbank- und Indexpfade; wenn nur die Bilder langsam sind, prüfen Sie den Speicher für Vorschaubilder, die Netzwerkübertragung, die Client-Dekodierung und konkurrierende Hintergrund-I/O.