Warum verarbeitet Immich vorhandene Daten nach einem Upgrade erneut?
Immich kann vorhandene Assets erneut verarbeiten, wenn ein Upgrade den Code, die Modelle, Metadaten oder Regeln für abgeleitete Daten ändert, die ein aktuelles Ergebnis definieren.
Die Originalfotos haben sich nicht verändert, doch Vorschaubilder, Embeddings, Gesichtsergebnisse, Vorschauen oder Datenbankeinträge erfüllen möglicherweise nicht mehr die Anforderungen der neuen Version. Im Folgenden wird präzise erklärt, welches Ergebnis ungültig wurde, welche Warteschlange es neu erzeugt und ob die Verarbeitung einmalig abgeschlossen wird oder sich ungewöhnlich wiederholt.
Ein Upgrade kann ändern, was als aktuelles Ergebnis gilt
Generierte Daten sind im Verhältnis zu dem Code, Modell, den Einstellungen und dem Schema gültig, durch die sie erzeugt wurden. Wenn sich diese Erwartungen ändern, gelten vorhandene Vorschaubilder, Embeddings, Gesichtsergebnisse oder Metadateneinträge möglicherweise nicht mehr als aktuell. Das Asset bleibt die Eingabe, auch wenn nur seine abgeleitete Darstellung neu verarbeitet werden muss.
Der ZimaSpace-Artikel zur Immich-Sicherung unterscheidet zwischen wichtigen Originalen und dem Datenbankstatus sowie regenerierbaren abgeleiteten Daten. Diese Unterscheidung erklärt, warum die Verarbeitung nach einem Upgrade umfangreich sein kann, ohne dass daraus folgt, dass Originaldateien dupliziert wurden: Die Anwendung erstellt möglicherweise den abgeleiteten Status rund um unveränderte Medien neu.
Notiere, welche Warteschlangen unmittelbar nach dem Upgrade wachsen und welche Verzeichnisse oder Datenbankgrößen sich ändern. Eine Vorschaubild-Warteschlange, eine Warteschlange für maschinelles Lernen und eine Datenbankmigration stehen für unterschiedliche Mechanismen. Sie alle als „Reindizierung“ zu bezeichnen, beseitigt die Hinweise, die zur Einschätzung von Dauer und Ressourcenbelastung erforderlich sind.
Änderungen an Abhängigkeiten und Modellen können frühere Verarbeitung ungültig machen
Immich umfasst Anwendungscode, Datenbankverhalten, Warteschlangenkoordination, Modelle für maschinelles Lernen und abgeleitete Mediendaten. Ein Upgrade kann Schnittstellen oder Erwartungen an die gespeicherte Darstellung zwischen diesen Komponenten verändern. Eine Migration kann Einträge schnell aktualisieren, während Hintergrund-Worker später für jedes betroffene Asset aufwendige Ergebnisse neu erzeugen.
Eine Community-Diskussion über die Vorbereitung auf Immich v3 macht die Unsicherheit in Bezug auf PostgreSQL, Redis, Vektorerweiterungen und Anwendungsversionen deutlich. Die Diskussion belegt keine bestimmte Upgrade-Maßnahme, zeigt aber, dass die Kompatibilität der Abhängigkeiten Teil des Zustandsübergangs und kein davon unabhängiges Wartungsdetail ist.
Bewahre die Versionsstände der Komponenten vor dem Upgrade sowie eine Momentaufnahme der Warteschlangen danach auf. Wenn nur eine Ergebnisklasse eingeplant wird und die Verarbeitung einmalig abgeschlossen wird, entspricht das einer begrenzten Regenerierung. Wenn Komponenten sich beim Schema oder bei Erweiterungen widersprechen, können wiederholte Fehler auftreten, bevor eine sinnvolle erneute Verarbeitung überhaupt beginnt.
Erneute Verarbeitung verwandelt Kompatibilitätsarbeit in Ressourcenbelastung
Eine umfangreiche Bibliothek kann aus einer einzigen geänderten Regel Tausende Aufgaben erzeugen. Die Erstellung von Vorschaubildern und die Medienanalyse beanspruchen CPU oder Beschleuniger, während das Lesen der Originale und das Schreiben der abgeleiteten Daten die Speicherbandbreite belasten. Datenbankaktualisierungen und Warteschlangenaktivität laufen gleichzeitig weiter, sodass das Browsen im Vordergrund langsamer werden kann, selbst wenn die erneute Verarbeitung ordnungsgemäß läuft.
Ein Immich-Supportthread berichtet von hoher nächtlicher CPU-Auslastung und einer erneuten Erstellung von Vorschaubildern nach einem Update auf zwei Servern. Dies ist ein Erfahrungsbericht und kein Beleg für das beabsichtigte Verhalten, liefert aber genau das Beobachtungsmuster, das anhand von Warteschlangenfortschritt, Protokollen und wiederholtem Abschluss überprüft werden sollte.
Verfolge die pro Minute abgeschlossenen Aufgaben, den freien Speicherplatz, die Geräte-Latenz, den Speicherdruck und eine festgelegte interaktive Anfrage. Eine gesunde erneute Verarbeitung sollte einen begrenzten Rückstand verringern. Eine geringere Parallelität kann die Nutzung im Haushalt schützen, verlängert jedoch die Dauer; zusätzliche Worker können die Konkurrenz um Speicher oder Datenbank verschärfen, wenn diese Phasen bereits den Engpass bilden.
Einmalige Regenerierung von einem sich wiederholenden Fehler unterscheiden
Speichere vor dem Upgrade die Anzahl der Aufgaben, Versionen, den freien Speicherplatz und die Kennungen mehrerer bekannter Assets. Überprüfe danach dieselben Kennungen stichprobenartig und notiere, welches Ergebnis neu erstellt wird, ob die Anzahl der Aufgaben sinkt und ob die Verarbeitung nach einem Neustart oder beim nächsten geplanten Wartungsfenster wieder einsetzt.
Eine Diskussion zur Wiederherstellung von Vorschaubildern berichtet, dass fehlende Bilder nach dem Abschluss der Verarbeitung wieder erschienen, während eine manuelle Aktualisierung bei einzelnen Assets half. Die unterschiedlichen Berichte unterstreichen die Abgrenzung: Die verstrichene Zeit allein kann das Verhalten nicht klassifizieren; ein endlicher Fortschritt der Warteschlange unterscheidet sich davon, dass dieselben Assets wiederholt fehlschlagen oder erneut eingeplant werden.
Behandle stetig sinkende Warteschlangen bei stabilen Ergebnissen als einmalige Regenerierung. Leite weitere Untersuchungen ein, wenn die Anzahl abgeschlossener Aufgaben zurückgesetzt wird, identische Assets wiederkehren, sich Fehler wiederholen, der freie Speicherplatz rapide abnimmt oder kein nennenswerter Durchsatz erkennbar ist. Bewahre Sicherungen und Protokolle, bevor du den Aufgabenstatus änderst, da das Löschen von Belegen verschleiern kann, ob das Upgrade oder die Umgebung die Schleife ausgelöst hat.
Empfohlene Produkte
Tech- & KI-Zentrum
Mehr zum Lesen
Welche Abhängigkeiten setzen der tatsächlichen Immich-Leistungsgrenze am häufigsten Grenzen?
Immich wird auf jedem gemessenen Pfad durch die langsamste Abhängigkeit begrenzt, sodass Upload, Suche, Durchsuchen und Wiedergabe unterschiedliche Obergrenzen haben können.
Immich-Netzwerk: Wie Erkennung, DNS und Routing Erreichbarkeit ermöglichen
Immich ist nur erreichbar, wenn die Auswahl des Endpunkts, DNS, Routing, NAT- oder Proxy-Verarbeitung, TLS und die Antwort der Anwendung einen gültigen Pfad bilden.
Immich für Familien: Wie Identität und Berechtigungen das Nutzungserlebnis prägen
Die Nutzung von Immich in der Familie hängt von getrennten Identitäten, dem Besitz von Assets, gezieltem Teilen, eingeschränkter Administration und einer getesteten Aufhebung von...
