Warum steigt die Hintergrundauslastung von Immich nach einer Bibliotheksänderung an?

Die Hintergrundverarbeitung von Immich kann nach einer Änderung an einer Bibliothek stark ansteigen, weil sich ein einzelnes Dateisystem- oder Bibliotheksereignis auf Scan-, Metadaten-, Derivat- und Indexierungsaufgaben ausweiten kann.

Wichtig ist die Unterscheidung zwischen einer begrenzten Welle erwartbarer erneuter Verarbeitung und Aufgaben, die Assets wiederholt ohne entsprechende Änderung erneut verarbeiten. Das Verschieben eines Ordners, ein erneuter Scan einer externen Bibliothek, neu entdeckte Dateien oder versionsabhängiges Verhalten können ähnliche CPU- und Warteschlangendiagramme erzeugen. Daher muss das Bibliotheksereignis den konkret erstellten Aufgaben zugeordnet werden.

Ein Bibliotheksscan ist eine Erkennungsphase, nicht die gesamte Arbeitslast

Bei einem Scan gleicht Immich zunächst ab, was auf dem Datenträger sichtbar ist, mit dem, was bereits über die Bibliothek bekannt ist. Beim Erkennen eines neuen oder geänderten Assets können nachgelagerte Ausgaben veraltet sein oder fehlen, wodurch nach dem scheinbaren Abschluss des Scans zusätzliche Arbeit entsteht.

Ein Erfahrungsbericht zu überlappenden Bibliotheksscans beschreibt, wie eine Scan-Warteschlange abgeschlossen wurde, während die Warteschlangen für Miniaturbilder, Gesichtserkennung und andere Aufgaben noch stark gefüllt waren. Der entscheidende Mechanismus ist die Ausweitung: Eine kurze Erkennungsphase kann eine deutlich längere Verarbeitungskette erzeugen.

Lesen Sie die Warteschlangen in Abhängigkeitsreihenfolge. Wenn die Bibliothekswarteschlange auf null fällt, während Warteschlangen für abgeleitete Daten weiter abgearbeitet werden, verarbeitet der Server möglicherweise einfach Aufgaben, die vom abgeschlossenen Scan erzeugt wurden. Den gesamten Zeitraum als wiederholten Scan zu bezeichnen, verschleiert, welche Phase tatsächlich Ressourcen nutzt.

Pfadänderungen können wie Arbeit an neuen Assets aussehen

Externe Bibliotheken reagieren besonders empfindlich auf Änderungen an Dateisystemidentität und Pfaden. Wenn Dateien neu organisiert werden, muss die Anwendung möglicherweise ihre neuen Speicherorte mit dem gespeicherten Asset-Zustand abgleichen. Je nach Verhalten der verwendeten Version und des Bibliothekstyps kann dadurch mehr Arbeit entstehen, als die Anzahl der tatsächlich neuen Fotos vermuten lässt.

Eine Diskussion aus dem Jahr 2026 über verschobene externe Dateien dokumentiert einen Fall, in dem neu organisierte Pfade als neue Assets behandelt wurden und erneut Miniaturbilder, ML-Analysen und Videoverarbeitung auslösten. Das ist ein Bericht über eine bekannte Einschränkung und keine Zusicherung, dass sich jeder Ordnerumzug identisch verhält.

Das erklärt, warum die Neuorganisation einer Bibliothek deutlich teurer sein kann als das Hinzufügen derselben Anzahl neuer Fotos. Wenn sich Dateipfade und Inhalte jedoch nicht geändert haben, deutet eine wiederholte vollständige Neugenerierung auf eine andere Ursache hin und sollte untersucht werden, statt sie als normales Hintergrundverhalten hinzunehmen.

Nachgelagerte Warteschlangen können wachsen, während die Verarbeitung fortschreitet

Die Anzahl wartender Aufgaben muss nicht kontinuierlich sinken. Wenn eine Aufgabe abgeschlossen wird, kann sie ein Asset für eine weitere Aufgabe qualifizieren oder zusätzliche Aufgaben in einer späteren Phase hinzufügen. Während eines umfangreichen Abgleichs kann der Server daher gleichzeitig aktiven Fortschritt und eine wachsende nachgelagerte Warteschlange anzeigen.

Die Diskussion über einen Rückstand bei Miniaturbildern weist darauf hin, dass neue Aufgaben zur Miniaturbilderstellung erscheinen können, während andere Verarbeitungsschritte abgeschlossen werden. Sie zeigt außerdem eine wichtige Grenze: Historische Fehler und falsch konfigurierte Importpfade können problematische Schleifen erzeugen. Eine wachsende Warteschlange muss daher im Kontext von Version und Pfadkonfiguration interpretiert werden.

Verwenden Sie Zähler für abgeschlossene Aufgaben und prüfen Sie stichprobenartig aktuelle Ausgaben, statt nur die Anzahl der wartenden Aufgaben zu betrachten. Wenn Miniaturbilder erscheinen, die Zahl der Abschlüsse steigt und die Abschlussrate schließlich die Zahl neuer Aufgaben übertrifft, wird die Warteschlange abgearbeitet, selbst wenn ihr Höchststand erst nach dem Ende des ursprünglichen Bibliotheksscans erreicht wird.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Ein Spitzenwert ist anormal, wenn keine passende Änderung vorliegt

Erwartbare Hintergrundlast sollte auf ein klar definiertes Ereignis zurückführbar sein: neue Assets, eine Aktualisierung von Metadaten, ein geänderter Pfad, eine Modelländerung oder eine ausdrücklich gestartete Neugenerierung. Die Erklärung wird schwächer, wenn dieselben alten Assets ohne Änderung an Konfiguration oder Inhalt wiederholt eingeplant werden.

Ein aktueller Bericht, in dem ein Scan andere Bibliotheken beeinflusste, offenbarte eine erneute Verarbeitung über mehrere externe Bibliotheken hinweg und zeigt, warum der Umfang wichtig ist. Betrachten Sie solche Berichte als versionsgebundene Hinweise, die Sie mit Ihren eigenen Protokollen vergleichen, nicht als grundlegendes Verhalten von Immich.

Der Mechanismus erklärt außerdem keinen Host, der noch lange aktiv bleibt, nachdem die relevanten Warteschlangen leer sind. Prüfen Sie in diesem Fall Datenbankwartung, Sicherungen, einen anderen Container, Dateisystemaktivität oder einen hängenden Prozess. Eine Bibliotheksänderung sollte nicht als pauschale Erklärung für dauerhaft hohe, unabhängige Last dienen.

Ordnen Sie die Änderung mithilfe einer Aufgabenübersicht davor und danach zu

Erfassen Sie vor einer kontrollierten Änderung an der Bibliothek die Asset-Anzahl, die wartenden und aktiven Aufgaben für wichtige Verarbeitungsschritte, die CPU-Auslastung, die Speicherlatenz und den Zeitpunkt des letzten abgeschlossenen Scans. Fügen Sie eine kleine, bekannte Gruppe hinzu oder verschieben Sie sie, wiederholen Sie dieselbe Beobachtung und halten Sie genau fest, welche Warteschlangen wachsen und wie schnell sie wieder geleert werden.

Nutzen Sie die Erklärung von ZimaSpace zum Immich-Datenpfad, um jede Spitze der Erkennung, Verarbeitung, Datenbank oder Speicherung zuzuordnen, statt sämtliche Hintergrundaktivität als eine einzige Kategorie zu behandeln.

Akzeptieren Sie die Spitzenlast, wenn die erzeugte Arbeit proportional zur kontrollierten Änderung ist, Ausgaben erscheinen, Fehler begrenzt bleiben und die Warteschlangen wieder zum Ausgangsniveau zurückkehren. Untersuchen Sie die Ursache weiter, wenn unveränderte Assets wiederholt neu verarbeitet werden, der Umfang über die bearbeitete Bibliothek hinausgeht oder dieselben Aufgaben ohne Fortschritt immer wieder fehlschlagen.