So erkennen Sie, ob Immich durch CPU, RAM, Speicher oder Netzwerk begrenzt wird

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 Tell Whether Immich Is Limited by CPU, RAM, Storage, or Network - Zima Store Online

Zeige, was Immich begrenzt, indem du einen festgelegten Upload-, Browse-, Such- oder Hintergrundjob-Workload reproduzierst und dessen Abschlussrate im selben Zeitraum mit CPU-Auslastung, Speicherdruck, Speicherlatenz und Netzwerkdurchsatz korrelierst.

Ein hoher Prozentsatz allein ist kein Engpass: Eine voll ausgelastete CPU kann beim maschinellen Lernen normal sein, hoher RAM-Verbrauch kann durch den Dateisystem-Cache entstehen, und ein langsamer Upload kann durch das Smartphone oder WLAN verursacht werden. Miss vom Client über Container und Host hinweg, erfasse den Warteschlangenfortschritt, ändere anschließend eine vermutete Einschränkung und wiederhole den Test. Die Ressource, deren Entlastung denselben Workload verbessert, ist die maßgebliche Begrenzung.

Einen reproduzierbaren Test und Zeitplan erstellen

Wähle das Symptom, das du verbessern möchtest: das Einlesen eines festen Medienpakets, das Öffnen nicht zwischengespeicherter Originale, die Erstellung von Vorschaubildern, die Ausführung der intelligenten Suche oder die Transkodierung eines Videos. Erfasse Startzeit, erstes nutzbares Ergebnis, Abschluss, Fehler und die Bewegung in der Job-Warteschlange. Wenn du Aufgaben vermischst, entstehen zwar Ressourcendiagramme, aber keine klare Entscheidung.

Eine Untersuchung durch einen Nutzer beschreibt eine ungewöhnlich langsame Immich-Bereitstellung und sucht nach Hinweisen zu CPU, Arbeitsspeicher, Datenträger und Netzwerk. Die ressourcenübergreifende Diagnoseperspektive ist nützlich, aber dein fester Test muss die Ursache auf deinem Server bestimmen.

Wiederhole den Test einmal, nachdem die Caches aufgewärmt sind. Wenn der zweite Durchlauf deutlich schneller ist, kennzeichne den Cache-Zustand, statt die Hardware als inkonsistent zu bezeichnen. Wenn beide Durchläufe in derselben Phase ins Stocken geraten, gleiche diesen Zeitpunkt mit den Host- und Container-Metriken sowie dem zuständigen Job ab.

CPU- und Speichersignaturen erkennen

Eine CPU-Begrenzung zeigt sich durch anhaltend ausführbare Arbeit auf den relevanten Kernen, während der Job proportional voranschreitet; eine geringere Parallelität kann die Interaktion verbessern, aber die Abarbeitungszeit verlängern. Wenn ein Thread voll ausgelastet ist, während die gesamte CPU-Auslastung moderat wirkt, prüfe zunächst die Ansicht pro Prozess und pro Kern, bevor du freie Kapazität annimmst.

Eine Speicherbegrenzung erfordert Hinweise auf Speicherdruck: zunehmende Auslagerung, Rückgewinnung, große Seitenfehler, OOM-Kills oder Neustarts von Containern. Hoher belegter Speicher bei stabilem Cache, ohne Auslagerung und mit normaler Latenz besteht diesen Test nicht. Wiederhole den Test mit einem Worker mit geringerer Parallelität oder einem kleineren Modell und vergleiche den Abschluss.

Ein gemeldeter Fall mit Immich v2.5.5 zur Erstellung von Vorschaubildern verbrauchte bei einer Bereitstellung extrem viel Speicher. Der versionsgebundene Speicherbericht spricht dafür, den fehlschlagenden Job und die Version zu prüfen; er legt jedoch keinen normalen RAM-Bedarf fest.

Speicherlatenz vom Netzwerkdurchsatz trennen

Beobachte beim exakten Job die Gerätelatenz, Warteschlangentiefe, den Durchsatz sowie den verfügbaren Dateisystemspeicher und die verfügbaren Inodes. Ein niedriger Megabyte-pro-Sekunde-Wert kann trotzdem auf eine Speicherbegrenzung hindeuten, wenn viele kleine Datenbank- und Vorschaubildoperationen auf einem Datenträger mit hoher Latenz warten.

Miss am Client und am Server und vergleiche anschließend lokale und entfernte Pfade. Eine ausgelastete Verbindung, erneute Übertragungen, WLAN-Wiederholungen oder ein VPN-Limit, das zeitgleich mit der Übertragung auftritt, weist auf eine Netzwerkbegrenzung hin. Wenn der Upload-Datenverkehr endet, die Verarbeitung aber langsam bleibt, verfolge stattdessen die serverseitige Warteschlange.

Die Übersicht von ZimaSpace zu Diensten auf älterer Hardware bietet Kontext für die Systemplanung; diese Diagnose sollte sich dennoch auf beobachtete Latenz und Arbeitsrate statt auf Alterskategorien stützen.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Eine Einschränkung beseitigen und denselben Workload überprüfen

Ändere eine sichere Variable: Reduziere die Parallelität eines Jobs, füge vorübergehend einen Speicherkapazitätstest hinzu, verschiebe eine Kopie der aktiven Daten auf schnelleren Speicher oder teste über ein kabelgebundenes lokales Netzwerk. Halte Datensatz, Versionen und Cache-Zustand vergleichbar. Eine Verbesserung sowohl beim Abschluss als auch bei der vorhergesagten Metrik besteht den Kausalitätstest.

Kaufe keine Hardware aufgrund eines Leerlaufdurchschnitts oder eines einzelnen Spitzenwerts. Eine Ressource ist ein sinnvolles Upgrade, wenn sie wiederholt den wichtigen Workload begrenzt, nachdem Softwarefehler, Probleme mit freiem Speicherplatz und konkurrierende geplante Aufgaben ausgeschlossen wurden.

Mach Änderungen rückgängig, die den Fehler auf eine andere Ebene verlagern oder Warteschlangen über das Dienstziel hinaus verlängern. Eskaliere mit Workload-Definition, Zeitstempeln, Metriken pro Container, Datenträgerlatenz, Netzwerktests, Warteschlangenfortschritt und Protokollen, wenn das System ins Stocken gerät, ohne dass eine Ressource Druck zeigt; dieses Muster kann auf eine Sperre, eine Abhängigkeit oder einen Anwendungsfehler hindeuten.