Wie viele gleichzeitigen Aufgaben kann Immich verarbeiten, bevor die Reaktionsfähigkeit der Suche nachlässt?

Für Immich gibt es keine universell sichere Aufgabenanzahl. Die Suche wird langsamer, wenn gleichzeitig laufende Worker die Ressource auslasten, die auch interaktive Anfragen benötigen.

Zwei Server können dieselbe Anzahl an Thumbnail-, Metadaten- und Machine-Learning-Aufgaben ausführen und dennoch sehr unterschiedliche Suchlatenzen aufweisen. Die sinnvolle Grenze ist daher die höchste gemischte Arbeitslast, bei der ein festgelegtes Ziel für interaktive Antwortzeiten eingehalten wird und die Warteschlange weiterhin abgearbeitet wird.

Eine Aufgabenanzahl beschreibt die Arbeitslast nicht

Ein Parallelitätswert ist lediglich eine Worker-Begrenzung und kein direktes Maß für die Auslastung. Thumbnail-Erstellung, Videotranskodierung, Metadatenextraktion und Machine-Learning-Inferenz verursachen unterschiedlich viel Rechen- und Speicherarbeit. Vier leichte Metadatenaufgaben können die Benutzeroberfläche responsiv halten, während zwei Videoaufgaben denselben Host deutlich stärker beanspruchen.

Ein Community-Bericht über eine hohe CPU-Auslastung durch Machine Learning beschreibt, wie nach einem großen Import die Anzahl gleichzeitig laufender Aufgaben reduziert wurde. Dadurch sank die Auslastung, während sich die Abschlusszeit verlängerte. Diese Beobachtung bestätigt den zentralen Zielkonflikt: Eine geringere Parallelität schützt die Reaktionsfähigkeit im Vordergrund, indem sie den Rückstand langsamer abbaut, nicht indem sie die zugrunde liegende Arbeit entfernt.

Betrachte jede Warteschlange als eigene Arbeitslastklasse. Erfasse, welche Aufgaben aktiv sind, welchen Medientyp sie verarbeiten und ob eine Beschleunigung verfügbar ist. Eine aus kleinen JPEGs abgeleitete sichere Gesamtzahl lässt sich nicht auf RAW-Fotos oder lange Videos übertragen, weil sich die durch jeden Slot repräsentierte Arbeit geändert hat.

Die Suche wird am ersten gemeinsamen Sättigungspunkt langsamer

Eine interaktive Suche durchläuft mehrere gemeinsam genutzte Ebenen: Die Anfrage erreicht die Anwendung, die Datenbank wählt Ergebnisse aus, Thumbnails werden gelesen und ein Client zeigt sie an. Hintergrund-Worker können auf mehr als einer Ebene konkurrieren. Die zuerst gesättigte Ebene wird zur praktischen Parallelitätsgrenze, selbst wenn jeder Container weiterhin fehlerfrei läuft.

Eine Leistungsdiskussion zu Immich beschreibt verzögertes Laden von Thumbnails auf einem Host mit nominell ausreichender Bandbreite. Das veranschaulicht, warum die Verbindungsgeschwindigkeit allein den Engpass nicht bestimmen kann. CPU-Zuteilung, Datenbankzugriffe, Dateisystemlatenz und die Auslieferung an den Client bleiben mögliche Ursachen, bis Messungen zeigen, welche Wartezeit während der langsamen Anfrage zunimmt.

Die Auslastung muss zusammen mit der Verzögerung betrachtet werden. Eine hohe CPU-Auslastung bei stabiler Suchlatenz kann eine produktive Sättigung bedeuten, während eine moderate CPU-Auslastung mit steigender Festplattenwartezeit auf eine Speicherwarteschlange hindeuten kann. Speicherdruck ist relevant, wenn Reclaim oder Swap Verzögerungen verursachen, nicht allein deshalb, weil das Betriebssystem verfügbaren RAM als Cache nutzt.

Die Suchbarkeit kann hinterherhinken, ohne dass Suchanfragen langsam sind

Eine schnelle Abfrage kann eine unvollständige durchsuchbare Sammlung zurückgeben, wenn neu hinzugefügte Assets ihre Indexierungsarbeit noch nicht abgeschlossen haben. Umgekehrt können alle Elemente bereits indexiert sein, während Abfragen wegen konkurrierender Datenbank- oder Speicherzugriffe langsam sind. Beide Zustände als „Verschlechterung der Suche“ zu bezeichnen, verschleiert zwei unterschiedliche Endpunkte und führt zur falschen Anpassung der Parallelität.

Die Erklärung von ZimaSpace zum Immich-Datenpfad unterscheidet die Annahme von Uploads, die Bereitschaft von Vorschauen und den semantischen Abruf als separate Endpunkte. Diese Unterscheidung ist bei Lasttests entscheidend: Der Zeitpunkt, an dem eine Datei eintrifft, kann nicht den Zeitpunkt ersetzen, an dem ihre Repräsentation für die Suche verfügbar ist.

Verfolge für eine festgelegte Importgruppe zwei Zeitmessungen. Die eine misst die Latenz interaktiver Abfragen anhand bereits indexierter Kontrollfotos. Die andere misst die Zeit, bis neu importierte Fotos bei vorab festgelegten Suchen erscheinen. Die erste schützt die aktive Benutzererfahrung, während die zweite die Durchsatzkosten einer geringeren Parallelität sichtbar macht.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Bestimme die Grenze mit einem Stufentest statt mit einer Schätzung

Erstelle einen repräsentativen Medienbestand und wähle drei festgelegte Suchen aus, die bekannte Assets zurückgeben. Beginne mit einem Worker in jeder aktiven Warteschlange, führe den Import aus und erfasse im selben Beobachtungszeitraum die mediane Suchlatenz sowie die Latenz im langsamen Randbereich, die Abbaugeschwindigkeit der Warteschlange, CPU-Auslastung, Speicherdruck, Netzwerkdurchsatz und die Speicherwartezeit.

Allgemeine Hinweise zu Engpässen empfehlen, Änderungen der Arbeitslast mit Wartezeiten bei CPU, Speicher, Datenträger, Netzwerk und Abhängigkeiten zu korrelieren, statt die am stärksten ausgelastet wirkende Grafik auszuwählen. Erhöhe pro Durchlauf nur eine Parallelitätsbegrenzung. Wenn du dieselbe Suchsequenz und dieselbe Mediengruppe wiederholst, bleibt die veränderte Variable eindeutig.

Beende den Test beim ersten Schritt, an dem das Ziel für die Suchlatenz im langsamen Randbereich verfehlt wird, der Server zu swappen beginnt, die Speicherwartezeit erhöht bleibt, Fehler auftreten oder die Hintergrundwarteschlange keinen nützlichen zusätzlichen Durchsatz mehr erzielt. Wiederhole den vorherigen Schritt nach einem Kaltstart und erneut im warmen Zustand. Dieser niedrigere, reproduzierbare Schritt ist die belastbare Obergrenze für diese Arbeitslast.