So verkürzen Sie die Immich-Startzeit nach einem Neustart

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.

How to Reduce Immich Startup Time After Reboot - Zima Store Online

Wenn Immich erst nach dem Neustart des Heimservers langsam nutzbar wird, messen Sie, welche Abhängigkeit zuletzt bereit ist, bevor Sie versuchen, die Anwendung selbst zu „beschleunigen“.

Ein Neustart kann dazu führen, dass Speicherbereitstellungen, PostgreSQL, Netzwerkpfade, DNS oder andere Dienste in einer anderen Reihenfolge verfügbar werden als bei einem normalen Immich-Neustart. Die aussagekräftige Kennzahl ist nicht, wann Docker meldet, dass ein Container gestartet wurde, sondern die Zeit vom Hochfahren des Hosts bis zu dem Zeitpunkt, an dem die Datenbank echte Anfragen akzeptiert, der benötigte Speicher eingebunden ist, Immich nicht mehr versucht, Abhängigkeiten zu erreichen, und ein Client die Zeitleiste laden kann. Erfassen Sie diese Abfolge einmal und entfernen Sie anschließend die tatsächliche Warte- oder Wiederholungsschleife.

Messen Sie die Startzeitleiste, bevor Sie etwas ändern

Starten Sie den Host in einem Wartungsfenster neu und erfassen Sie Zeitstempel für vier Punkte: Host erreichbar, Immich-bezogener Speicher eingebunden, Datenbank gesund und Immich über einen Client nutzbar. Erfassen Sie außerdem die Startzeiten der Container, Gesundheitszustände, Neustartzähler und die erste nützliche Protokollzeile jedes Dienstes. So wird aus „Der Start fühlt sich langsam an“ eine klar begrenzte Verzögerung.

Vergleichen Sie das Ergebnis mit einem normalen Neustart des Stacks, nachdem der Host bereits vollständig hochgefahren ist. Wenn Immich später schnell neu startet, aber nur beim Systemstart langsam ist, liegt der Engpass wahrscheinlich an einer Reihenfolge oder einer Bereitschaftsabhängigkeit außerhalb der Anwendung. Wenn beide Abläufe gleich langsam sind, untersuchen Sie stattdessen Datenbankaktivitäten, Speicherlatenz, Migrationen oder CPU-Auslastung.

Optimieren Sie nicht alle Ebenen gleichzeitig. Am Ende dieses Schritts sollte feststehen, welche Komponente erst nach dem Start ihres Containers bereit wird oder Immich wiederholt zu neuen Verbindungsversuchen zwingt.

Prüfen Sie, ob der Speicher vor dem Start von Immich bereit ist

Stellen Sie sicher, dass jede Bind-Bereitstellung und jeder netzwerkbasierte Pfad vorhanden ist und die erwarteten Daten enthält, bevor die Immich-Dienste starten. Ein Bereitstellungspunkt kann als leeres lokales Verzeichnis existieren, während die eigentliche Festplatte oder NAS-Freigabe noch nicht verfügbar ist. Dadurch kann die Anwendung mit einer falschen Ansicht des Dateisystems starten.

Wenn sich Ihre Datenbank oder Ihre Mediendateien auf Speicher befinden, der beim Systemstart spät verfügbar wird, lassen Sie den Dienst auf Hostebene von dieser Bereitstellung abhängen oder verzögern Sie den Stack, bis das Vorhandensein der Bereitstellung nachweislich bestätigt wurde. Die Prüfung sollte das tatsächlich eingebundene Dateisystem oder eine bekannte Markierungsdatei kontrollieren, nicht nur, ob der Verzeichnisname vorhanden ist.

Starten Sie den Host nach der Anpassung der Speicherbereitschaft erneut und vergleichen Sie dieselben Zeitstempel. Eine erfolgreiche Änderung beseitigt Wiederholungsversuche oder das Verhalten mit leeren Pfaden, ohne die Immich-Konfiguration im laufenden Betrieb zu verändern. Wenn der Speicher bereits deutlich vor der Datenbank bereit ist, untersuchen Sie als Nächstes die Abfolge der Abhängigkeiten, statt beliebige Wartezeiten einzubauen.

Warten Sie, bis die Datenbank gesund ist, nicht nur bis sie läuft

PostgreSQL kann bereits einen laufenden Container haben, bevor es bereit ist, die von der Anwendung benötigte Arbeitslast anzunehmen – insbesondere nach einem unsauberen Stopp, einer verzögerten Speicherbereitstellung, der Initialisierung oder einer Wiederherstellung. Vergleichen Sie den Übergang des Datenbank-Gesundheitszustands mit den ersten Immich-Verbindungsfehlern in den Startprotokollen.

Eine einfache Startreihenfolge kann einen abhängigen Container starten, bevor der benötigte Dienst tatsächlich bereit ist. Wenn Ihre Compose-Version und die Dienstdefinitionen dies unterstützen, können gesundheitsbasierte Abhängigkeitsprüfungen zwischen „Container gestartet“ und „Abhängigkeit bereit“ unterscheiden. Verwenden Sie sie, um vermeidbare erneute Verbindungsversuche zu beseitigen, statt eine langsame oder fehlerhafte Abhängigkeit zu verbergen.

Halten Sie die Bereitschaftsprüfung eng gefasst und aussagekräftig. Eine Datenbankprüfung sollte nachweisen, dass sie die von Immich benötigte Verbindung akzeptieren kann; sie sollte keine aufwendige Abfrage ausführen, die selbst zusätzliche Verzögerungen verursacht. Sobald die Datenbank zuverlässig vor dem Start von Immich bereit ist, wiederholen Sie den Host-Neustarttest, bevor Sie etwas anderes ändern.

-15% OFF

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

Single board computer zimaboard2

Trennen Sie Wiederholungsschleifen von legitimer Startarbeit

Wenn Speicher und PostgreSQL bereit sind, Immich nach einem Neustart aber weiterhin deutlich länger benötigt, untersuchen Sie die Anwendungs- und Worker-Protokolle auf wiederholte Verbindungsfehler, fehlgeschlagene Gesundheitsprüfungen, Migrationen, Auftragsinitialisierung oder Ressourcenengpässe. Wiederholte Fehler in festen Abständen deuten häufig auf Wartezeiten hin; anhaltende CPU- oder Festplattenaktivität mit erkennbarem Fortschritt spricht dagegen für tatsächliche Startarbeit.

Eine Abhängigkeitsreihenfolge funktioniert am besten zusammen mit aussagekräftigen Gesundheitsprüfungen anstelle kurzer fester Verzögerungen. Ein Compose-Muster für Gesundheitsprüfungen kann verhindern, dass eine Anwendung mit einer noch initialisierenden Datenbank oder einem Cache um die Wette startet. Halten Sie die Prüfungen realistisch; kürzere Intervalle, bis ein fehlerhafter Dienst gesund erscheint, verbessern den Start nicht.

Wenn die Neustartzähler beim Systemstart steigen, unterbrechen Sie diese Kaskade und ermitteln Sie die erste nicht verfügbare Abhängigkeit, bevor Sie CPU-, Speicher- oder Parameter für den Image-Start anpassen. Eine Prüfung von Abhängigkeiten bei Container-Neustartschleifen hilft dabei, eine langsame Voraussetzung von einem Problem innerhalb von Immich zu unterscheiden.

Starten Sie den Host erneut und prüfen Sie die tatsächliche Nutzbarkeit

Führen Sie nach einer gezielten Änderung einen vollständigen Neustart des Hosts durch und erfassen Sie dieselben Zeitstempel. Eine echte Verbesserung sollte den Abstand zwischen der Bereitschaft der Abhängigkeiten und einem nutzbaren Immich-Client verkürzen, ohne neue Neustartschleifen, fehlende Bereitstellungen oder Hintergrundfehler zu verursachen.

Testen Sie mehr als nur die Web-Anmeldeseite. Öffnen Sie mehrere ältere Fotos, führen Sie eine Suche aus, laden Sie ein repräsentatives Video, bestätigen Sie die Verbindung eines Mobilclients und laden Sie ein nicht benötigtes Element hoch, damit sowohl Lese- als auch Schreibpfade geprüft werden. Für den Haushalt ist der Server erst dann „gestartet“, wenn diese normalen Vorgänge funktionieren.

Führen Sie nach dem ersten erfolgreichen Test einen zweiten Neustart durch, um sicherzustellen, dass das Ergebnis nicht nur auf einem Cache-Effekt oder einem einmaligen Netzwerkereignis beruht. Wenn der Start weiterhin unbeständig ist, bewahren Sie die Startprotokolle auf und konzentrieren Sie sich auf die Komponente, deren Bereitschaft zwischen den Durchläufen schwankt. Verbergen Sie diese Schwankungen nicht durch eine längere feste Verzögerung, solange es ein besseres Bereitschaftssignal gibt.