Warum verursacht Immich über Nacht wiederholte Festplattenaktivität?

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.

Why Does Immich Cause Repeated Disk Activity Overnight? - Zima Store Online

Immich kann über Nacht wiederholte Datenträgeraktivität erzeugen, weil geplante Wartungsarbeiten, Datenbankaktivitäten, eingereihte Medienaufgaben oder Wiederholungsversuche weiterlaufen, nachdem niemand mehr die Bibliothek nutzt.

Ein ruhiger Haushalt bedeutet nicht, dass der Server untätig ist. Die entscheidende Frage ist, ob derselbe Prozess und derselbe Auftrag die Lese- oder Schreibvorgänge zur gleichen Uhrzeit erklären. Ordnen Sie die Aktivität zunächst zu und entscheiden Sie anschließend, ob es sich um erwartete Arbeit, das Abarbeiten eines Rückstands oder eine Schleife handelt, die beendet werden sollte.

Ordnen Sie den Datenträgerschub der Uhrzeit zu, bevor Sie etwas ändern

Beginnen Sie mit Zeitstempeln aus drei Nächten statt mit einer einzigen unruhigen Beobachtung. Notieren Sie, wann die Block-E/A zunimmt, welches Gerät ausgelastet ist, ob Lese- oder Schreibvorgänge überwiegen und ob das Muster nahezu zur gleichen Zeit beginnt. Eine wiederkehrende Startzeit deutet auf einen Scheduler hin; ein unregelmäßiges Muster spricht eher für neue Eingänge, Wiederholungsversuche oder einen anderen Container.

Immich-Bereitstellungen können Datenbanksicherungen und Integritätsprüfungen während nutzungsarmer Zeiten einplanen, daher kann ein Schub am frühen Morgen beabsichtigt sein. Deaktivieren Sie einen Auftrag nicht nur deshalb, weil er die Datenträger aufweckt. Prüfen Sie zunächst, ob nach dem Aktivitätsfenster eine entsprechende Sicherung, ein Wartungsergebnis oder der Abschluss einer Warteschlange erscheint.

Die angrenzende ZimaSpace-Diagnose zu Hintergrundarbeiten von Immich während der Leerlaufzeit verwendet dieselbe Zeitstempelregel: Verknüpfen Sie das sichtbare Symptom mit dem Prozess und dem Auftrag, bevor Sie „Leerlauf“ als Fehlerzustand betrachten.

Trennen Sie PostgreSQL-Schreibvorgänge von Medienlesevorgängen

Änderungen am Anwendungsstatus von Immich können PostgreSQL aktiv halten, auch wenn kein neues Foto geöffnet wird. Datenbank-Checkpoints, Write-Ahead-Logging, Vacuum-bezogene Arbeiten und normale Anwendungsaktualisierungen haben ein anderes E/A-Muster als das Scannen Tausender Mediendateien. Ermitteln Sie den Pfad oder das Gerät, auf dem der Datenverkehr anfällt, bevor Sie die Fotobibliothek verantwortlich machen.

Die Diskussion zur PostgreSQL-Beobachtbarkeit in der pg_stat_io-Analyse erklärt, warum Lesevorgänge, Schreibvorgänge, Backend-Aktivität, Checkpointer-Verhalten und Hintergrundschreibvorgänge getrennt betrachtet werden müssen. Nutzen Sie diese Unterscheidung, um zu klären, ob das Datenbankgerät ausgelastet ist, weil nützliche Transaktionen gespeichert werden, oder weil etwas wiederholt unnötige Aktivität erzeugt.

Wenn Datenbankschreibvorgänge klein und periodisch sind, während die Mediendatenträger im Ruhezustand bleiben, kann es sich um normale Datenbankpflege handeln. Wenn dieselbe Datenbankdatei dauerhaft stark beschrieben wird, obwohl kein Auftrag voranschreitet, sichern Sie die Protokolle und untersuchen Sie die verantwortlichen Abfragen oder die Neustartschleife, statt die gesamte Bibliothek auf schnelleren Speicher zu verschieben.

Prüfen Sie, ob Hintergrundwarteschlangen tatsächlich vorankommen

Öffnen Sie die Auftragsansicht und vergleichen Sie ausstehende, aktive, fehlgeschlagene und abgeschlossene Arbeiten vor und nach dem nächtlichen Zeitfenster. Thumbnail-Erstellung, Videoverarbeitung, Metadatenextraktion, Aufgaben des maschinellen Lernens oder Arbeiten an einer importierten Bibliothek können den Speicher nach einer größeren Änderung legitimerweise aktiv halten. Ein schrumpfender Rückstand ist ein Hinweis auf nützliche Aufholarbeit.

Ein aktueller Community-Bericht über anhaltende ungeklärte Lesevorgänge zeigt die entgegengesetzte diagnostische Grenze: Sehr hohe kontinuierliche Leseraten ohne erwartete Arbeit sollten untersucht und nicht als „typisches Verhalten von Immich“ abgetan werden. Betrachten Sie die gemeldete Rate als Einzelfall, nicht als Richtwert.

Wenn dieselben wenigen Aufträge fehlschlagen und erneut in die Warteschlange gelangen, kann sich die Datenträgeraktivität wiederholen, ohne Fortschritt zu erzeugen. Erfassen Sie den ersten Fehler und ein betroffenes Asset und grenzen Sie anschließend diesen Auftragstyp ein. Leeren Sie nicht alle Warteschlangen und erstellen Sie nicht die gesamte Bibliothek neu, bevor Sie geklärt haben, ob die Schleife durch eine einzelne Datei, Berechtigungen, Speicherlatenz oder eine Dienstabhängigkeit verursacht wird.

-15% OFF

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

Single board computer zimaboard2

Ordnen Sie die E/A einem Prozess zu, statt anhand von Laufwerksgeräuschen zu raten

Verwenden Sie während des nächsten Auftretens eine E/A-Überwachung auf Host-Ebene, um den Prozess zu identifizieren, der auf das Gerät liest oder schreibt. Ordnen Sie diesen Prozess anschließend dem Immich-Server, PostgreSQL, dem maschinellen Lernen, einem Sicherungstool, einem Virenschutz, einer Dateisystemprüfung oder einem unabhängigen Container zu. Laufwerks-LEDs und Lüftergeräusche liefern diese Zuordnung nicht.

Ein praktischer iotop-Ablauf veranschaulicht die Methode „Prozess zuerst“. Zeichnen Sie mehrere Messungen auf, da ein kurzer Schub zwischen zwei Beobachtungen verschwinden kann. Ziel ist es, den Prozess während desselben Zeitfensters wie das Symptom zu erfassen.

Wenn Immich nicht der größte E/A-Verursacher ist, ändern Sie keine weiteren Immich-Einstellungen, sondern verfolgen Sie den tatsächlichen Prozess. Wenn PostgreSQL, Immich oder ein zugehöriger Worker verantwortlich ist, gleichen Sie dessen Protokolle und Auftragsfortschritt mit der E/A-Messung ab. So wird aus „Der Server ist jede Nacht laut“ eine konkrete Komponente mit einem konkreten Auslöser.

Definieren Sie die Grenze zwischen normaler nächtlicher Arbeit und einem Fehler

Betrachten Sie die Aktivität als normal, wenn sie zu einem bekannten Zeitplan oder einer kürzlich geänderten Bibliothek passt, nützliche Arbeit abschließt, die Zahl der Fehler nicht weiter steigt und Speicherlatenz sowie Warteschlangentiefe wieder auf den Ausgangswert zurückkehren. Halten Sie die normale Dauer fest, damit Sie spätere Verlängerungen vergleichen können.

Eine frühere Immich-Diskussion über häufige Datenbankschreibvorgänge zeigt, warum bestimmte Datenbankaktivitäten auch ohne sichtbare Benutzeraktion auftreten können. Da sich Versionen und Bereitstellungen ändern, sollte dieser Fall nur als Begründung dienen, die Datenbank separat zu messen, und nicht dazu, jeden dauerhaften Schreibvorgang als normal einzustufen.

Leiten Sie eine Untersuchung ein, wenn die E/A nach dem Ende der Warteschlangen fortgesetzt wird, dieselben Fehler wiederkehren, die Speicherlatenz die Nutzung am Tag beeinträchtigt, der freie Speicher unerwartet abnimmt oder das Muster von Nacht zu Nacht zunimmt. Sichern Sie Zeitstempel, Prozess-E/A, Auftragszahlen, relevante Protokolle, den freien Speicherplatz des Dateisystems und einen reproduzierbaren Auslöser, bevor Sie tiefgreifende Änderungen vornehmen.