Warum läuft ein Immich-Server während der Leerlaufzeiten heiß oder laut?

Ein Immich-Server läuft während Leerlaufzeiten häufig heiß oder laut, weil die Aktivitäten der Benutzer beendet sind, während sich ausstehende Miniaturansichten, Videotranskodierungen, maschinelles Lernen, Bibliotheks-Scans, Backups oder fehlgeschlagene Speicher-Wiederholungsversuche im Hintergrund fortsetzen.

Ermitteln Sie zunächst, welcher Prozess, Container, Auftrag und welches Gerät zum selben Zeitpunkt wie die Lüfteränderung aktiv ist. Ein produktives Abarbeiten der Warteschlange sollte sinkende Auftragszahlen zeigen und schließlich zur Ruhe kommen; eine Wiederholungsschleife erzeugt ohne Fortschritt immer wieder Fehler; ein Kühlungsproblem kann die Lüfter auch dann auf hoher Drehzahl halten, wenn Rechenlast und I/O zurückgehen. Diese Fälle erfordern unterschiedliche Lösungen. Deaktivieren Sie daher nicht anhand des Geräuschs allein sämtliche Hintergrundaktivitäten.

Geräusche mit Prozess-, Auftrags- und Geräteaktivität abgleichen

Protokollieren Sie CPU-Auslastung nach Prozess und Container, Temperaturen, Lüfterdrehzahl, Datenträgerauslastung, Netzwerkverkehr und Immich-Auftragszahlen während des lauten Zeitraums. Ein Durchlauf identifiziert eine Ressourcenspitze und deren Verursacher. Wenn alle Arbeitsmetriken niedrig sind, die Temperatur aber hoch bleibt, untersuchen Sie stattdessen Kühlung und Sensorsteuerung.

Eine Diskussion zu einer großen Bibliothek beschreibt, wie Gesichtserkennung einen Server zu wiederkehrenden Zeiten laut werden ließ. Die Korrelation zwischen Auftrag und Lüfter ist ein begrenztes Beispiel aus einem Haushalt und kein Beweis dafür, dass die Gesichtserkennung für jede nächtliche Spitze verantwortlich ist.

Vergleichen Sie die Startzeit mit kürzlich erfolgten Uploads, geplanten Scans, Backup-Zeitfenstern und Wartungsarbeiten am Host. Wenn die Geräusche nach einem Import beginnen und die Warteschlangentiefe abnimmt, handelt es sich um verzögerte Arbeit. Wenn sie zu einer festen Zeit ohne Uploads beginnen, verfolgen Sie den geplanten Dienst, der zuerst aktiv wird.

Produktive Verarbeitung von einer Wiederholungsschleife unterscheiden

Prüfen Sie die aktiven Warteschlangen für Miniaturansichten, Metadaten, Smart Search, Gesichter und Videotranskodierungen. Bei produktiver Arbeit werden Elemente abgeschlossen und die verbleibende Anzahl sinkt. Die wiederholte Verarbeitung eines einzelnen Elements, eine gleichbleibende Warteschlangentiefe, Neustarts von Containern oder wiederkehrende Abhängigkeitsfehler deuten auf einen Fehler statt auf einen normalen Rückstand hin.

Ein Benutzerbericht beschrieb eine ungewöhnlich hohe CPU-Auslastung über viele Kerne hinweg auf einem Immich-System. Die Untersuchung der hohen CPU-Auslastung spricht dafür, zunächst Belege zu Aufträgen und Prozessen zu sammeln, bevor man annimmt, dass die Kernanzahl oder ein scheinbarer Leerlauf den Normalzustand bestimmt.

Bei einem fehlerhaften Asset oder einer fehlerhaften Abhängigkeit bewahren Sie den Fehler auf und testen Sie nach der Behebung der Ursache einen kleinen Wiederholungsversuch. Bei legitimer, lang laufender Arbeit begrenzen Sie die Parallelität oder verlegen Sie sie in ein akzeptables Zeitfenster. Bestätigen Sie anschließend, dass die Warteschlange vor dem nächsten Durchlauf weiterhin auf null sinkt.

Speicher-Wiederholungsversuche, geplante Arbeiten und Kühlung prüfen

Achten Sie auf eine fehlende Netzwerkfreigabe, ein volles Dateisystem, einen langsamen Datenträger, eine Überschneidung mit Backups, Datenbankwartung, wachsende Containerprotokolle oder wiederholte Bibliotheks-Scans. Diese Faktoren können Datenträgerzugriffe und CPU-Auslastung verursachen, ohne dass offensichtliche Web-Clients aktiv sind. Ein stabil eingebundenes Laufwerk und ein fortschreitender Auftrag sprechen für einen normalen Ablauf; wiederholte Timeout-Zeilen weisen auf eine Reparatur von Speicher oder Netzwerk hin.

Nach Abschluss der Arbeitslast sollten Temperatur und Lüfterdrehzahl entsprechend der thermischen Trägheit der Hardware und der Regelkurve sinken. Beseitigen Sie blockierte Luftwege, überprüfen Sie Lüfter und Kühlkörperkontakt und untersuchen Sie die Lüfterregelung des Hosts erst, wenn Softwareaktivität ausgeschlossen ist. Stellen Sie keine unsichere, geräuscharme Regelkurve ein, um anhaltende Hitze zu kaschieren.

Der ZimaSpace-Artikel über die Organisation von Fotos mit einem KI-NAS erklärt, warum lokale Erkennung und Indizierung nach Abschluss der Uploads fortgesetzt werden können.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Passende Lösung anwenden und über Nacht überprüfen

Planen oder begrenzen Sie nur die nachweislich schwere Warteschlange, beheben Sie den Speicher- oder Abhängigkeitsfehler, trennen Sie Backup-Zeitfenster oder reparieren Sie die Kühlung. Notieren Sie die ursprüngliche Einstellung und löschen Sie den Auftragsverlauf nicht, bevor das neue Verhalten beobachtet wurde.

Wiederholen Sie den ursprünglichen Import oder warten Sie den gleichen Zeitplan ab. Der Test ist bestanden, wenn die Warteschlange erwartungsgemäß voranschreitet, kein Fehler wiederholt auftritt, die maximale Temperatur akzeptabel bleibt und die Geräuschentwicklung nach Abschluss der Arbeit wieder normal ist. Starten Sie den Server einmal neu, um zu überprüfen, dass Zeitpläne, Begrenzungen, Einbindungen und Lüftersteuerung erhalten bleiben.

Setzen Sie eine Verringerung der Parallelität zurück, wenn die Warteschlange nie geleert wird, und stoppen Sie die Rechenlast, wenn die Temperatur das Hardwarelimit überschreitet oder die Kühlung ausfällt. Liegt die Hitze weiterhin vor, nachdem die Arbeitslast null erreicht hat, eskalieren Sie das Problem mit synchronisierten Diagrammen, Auftragszahlen, dem ersten wiederholten Fehler, dem Medientyp, Versionsangaben und Beobachtungen zur Kühlung.