Während eines großen Imports aus einer mobilen Bibliothek kann Immich Assets schneller annehmen, als alle suchbezogenen Hintergrundaufgaben abgeschlossen werden. Daher kann die Aktualität der Suche hinter dem Abschluss des Uploads zurückbleiben.
Diese Verzögerung ist nur dann ein Planungsproblem, wenn die erforderlichen Aufgaben warten, ausgeführt werden oder um gemeinsame Ressourcen konkurrieren; sie ist nicht automatisch ein Suchfehler. Das nützliche Modell ist eine Pipeline: Eingehende Assets erzeugen Arbeit, Warteschlangen fangen Spitzen ab, Worker verarbeiten diese Warteschlangen, und die Datenbank erhält die Ergebnisse, auf denen spätere Suchen beruhen.
Große Importe erzeugen verschiedene Aufgaben in großer Zahl
Eine Migration von einem Mobilgerät macht mehr, als nur Bytes zu kopieren. Jedes akzeptierte Asset kann Folgeaufgaben für Vorschaubilder, Metadaten, Videoverarbeitung, die intelligente Suche, Gesichter oder andere aktivierte Funktionen erzeugen. Da diese Aufgaben unterschiedliche Kosten und Abhängigkeiten haben, kann ein einziger Import mehrere Rückstände mit unterschiedlichen Abarbeitungsraten erzeugen.
Die Anfrage nach sequenziellen Aufgaben zeigt, warum Nutzer dieses Verhalten auf leistungsschwächeren Hosts bemerken: Betreiber möchten umfangreiche Aktivitäten manchmal nacheinander statt gleichzeitig ausführen. Diese Anfrage ist ein Hinweis auf Ressourcenkonkurrenz, aber kein Beweis dafür, dass eine sequenzielle Ausführung für jeden Server am besten ist.
Messen Sie jede Warteschlange anhand von Eingängen, Abschlüssen und Fehlern, statt die Gesamtzahl ausstehender Aufgaben als eine einzige Arbeitslast zu betrachten. Ein großer Rückstand bei Vorschaubildern kann andere abhängige Arbeiten anders verzögern als ein Rückstand bei der Videotranskodierung. Außerdem hat eine stetig schrumpfende Warteschlange eine andere Bedeutung als eine, die dieselben Elemente wiederholt erneut versucht.
Die Priorität einer Warteschlange ist nicht dasselbe wie eine globale Ressourcensteuerung
Ein System kann ausgewählte Arbeiten priorisieren oder pausieren, während andere Aufgabentypen weiterhin aktiv sind. Deshalb garantiert ein Importwerkzeug, das eine bestimmte Klasse von Hintergrundaktivitäten reduziert, nicht zwangsläufig eine inaktive CPU, ruhige Datenträger oder eine sofort aktuelle Suche. Planungsrichtlinie und gesamter Ressourcenverbrauch hängen zusammen, sind aber nicht identisch.
Eine Version von immich-go führte während Uploads pausierte Hintergrundaufgaben ein, um Konflikte zu reduzieren. Dieses Verhalten gehört zu diesem Importer und dieser Version. Daher sollte daraus nicht die allgemeine Aussage abgeleitet werden, dass jeder mobile Immich-Import automatisch dieselben Aufgaben pausiert.
Die praktische Grenze ist der beobachtbare Fortschritt. Wenn Uploads schnell fortgesetzt werden, während suchbezogene Warteschlangen absichtlich pausiert sind, werden neue Assets naturgemäß erst später durchsuchbar. Ist die Warteschlange aktiviert, bleiben die Abschlüsse jedoch nahezu bei null, verlagert sich die Frage von der Planungsrichtlinie auf einen Fehler bei Worker, Ressourcen oder bestimmten Assets.
Parallelität kann den Durchsatz erhöhen und die Reaktionsfähigkeit verschlechtern
Mehr parallel arbeitende Worker können die Zahl abgeschlossener Aufgaben pro Minute erhöhen, bis eine gemeinsame Abhängigkeit an ihre Kapazitätsgrenze gelangt. Danach kann zusätzliche Parallelität die Wartezeit auf die Datenbank, die Speicherlatenz, den Speicherdruck oder den Kontextwechsel erhöhen. Dadurch werden Hintergrundaufgaben im Durchschnitt zwar schneller abgeschlossen, interaktive Anfragen weisen jedoch längere Spitzenlatenzen auf.
Ein Erfahrungsbericht über hängende Aufgabenwarteschlangen beschreibt eine große Bibliothek, bei der eine Verringerung der Parallelität den beobachteten Fortschritt verbesserte. Dies ist eine deploymentspezifische Beobachtung, zeigt aber, warum Parallelität als Variable der Arbeitslast getestet werden sollte, statt sie als festen Indikator für die Leistungsfähigkeit eines Servers zu betrachten.
Verwenden Sie eine bekannte Suche nach einem bereits indizierten Album als interaktive Kontrollabfrage. Bleibt diese Abfrage schnell, während die Abdeckung neuer Fotos hinterherhinkt, handelt es sich beim Import hauptsächlich um ein Aktualitätsproblem. Werden gleichzeitig selbst alte Abfragen langsamer und steigen CPU-, Speicher- oder Datenbankwartezeiten, verbraucht das Planungsfenster interaktive Reserven.
Eine wachsende Warteschlange ist nicht automatisch ein Fehler
Ein Rückstand wächst immer dann, wenn mehr Arbeit eintrifft, als die Worker abschließen. Während eines absichtlich durchgeführten historischen Imports ist das für einen gewissen Zeitraum zu erwarten. Das Fehlersignal ist nicht die maximale Länge der Warteschlange selbst, sondern die Kombination aus ausbleibenden Abschlüssen, wiederholten Fehlern oder einem Rückstand, der nach dem Ende der Eingänge nicht abgebaut wird.
Diskussionen über große Importe, etwa diese Migration mit 200.000 Fotos, zeigen, wie Betreiber den Upload-Durchsatz von der nachgelagerten Verarbeitung unterscheiden. Erfahrungen aus der Community sind hilfreich, um festzulegen, was gemessen werden sollte. Sie sollten jedoch nicht in eine allgemeingültige Zeitprognose für eine andere Bibliothek umgewandelt werden.
Dieser Mechanismus erklärt fehlende Suchergebnisse nicht mehr, wenn die relevante Aufgabe abgeschlossen ist und derselbe autorisierte Nutzer ein bekanntes Asset weiterhin nicht abrufen kann. Untersuchen Sie dann die Suchrelevanz, Filter, Berechtigungen, das Modellverhalten oder die Verarbeitung des betreffenden Assets, statt die Importparallelität weiter anzupassen.
Führen Sie einen zweigleisigen Planungstest durch
Richten Sie eine feste Spur für alte, bereits indizierte Inhalte und eine weitere für einen kleinen neuen Import ein. Erfassen Sie vor dem Import die Antwortzeit einer bekannten alten Suche. Während des Imports erfassen Sie regelmäßig dieselbe Suche, die Upload-Rate, die Anzahl ausstehender und abgeschlossener Aufgaben, Fehler, CPU-Auslastung, Speicherdruck und Speicherlatenz.
Nutzen Sie die Analyse von ZimaSpace zu dem Immich-Datenpfad, um die Phasen Übertragung, Verarbeitung, Speicherung und Suche voneinander getrennt zu betrachten. Ein Engpass ist nur dann direkt bearbeitbar, wenn er mit der Phase zusammenfällt, deren eigentliches Serviceziel verfehlt wird.
Akzeptieren Sie den Zeitplan, wenn alte Suchen innerhalb Ihrer im Haushalt akzeptierten Grenzen bleiben, die Warteschlangen für neue Elemente weiterhin Aufgaben abschließen und der Rückstand nach dem Ende der Eingänge abgebaut wird. Verringern oder verschieben Sie die Parallelität von Hintergrundaufgaben nur dann, wenn der kontrollierte Test zeigt, dass dieselbe gemeinsame Ressource sowohl die interaktive Nutzung als auch den Fortschritt der Warteschlange verzögert.
Tech- & KI-Zentrum
Mehr zum Lesen

Offene Modelle holen zur Spitzen-KI auf – wird 2026 das Jahr, in dem lokale KI gut genug wird?
Offene Modelle werden für immer mehr lokale KI-Workloads gut genug, während hochmoderne Cloud-Modelle für die anspruchsvollsten Aufgaben in den Bereichen Schlussfolgern und Agenten weiterhin...

NVIDIA PAIR verwandelt Ihr Heimnetzwerk in einen lokalen KI-Cluster – brauchen Sie noch einen großen GPU-Server?
NVIDIA PAIR verteilt lokale KI-Anfragen auf mehrere PCs und macht die Rechenleistung dadurch flexibler, während ein einzelner Heimserver Daten und Zustand dauerhaft speichern kann.

Warum fühlt sich Immich im LAN schneller an als bei Fernverbindungen?
LAN-Anfragen nehmen in der Regel einen kürzeren Weg mit geringerer Latenz. Der Fernzugriff bringt Kapazitätsbeschränkungen des WANs mit sich und kann zusätzliche DNS-, TLS-,...

