So testen Sie, ob Immich durch CPU, Arbeitsspeicher, Netzwerk oder Speicher begrenzt wird

Testen Sie Immich mit einem einzigen wiederholbaren Vorgang, setzen Sie dessen Latenz in Beziehung zu Ressourcenwartezeiten und bestätigen Sie den vermuteten Engpass durch einen kontrollierten Eingriff.

Ein Dashboard-Schnappschuss kann nicht zwischen nützlicher Aktivität und schädlicher Konkurrenz um Ressourcen unterscheiden. Messen Sie einen Endpunkt – etwa die Annahme eines Uploads, die Anzeige von Miniaturbildern oder die Antwort der intelligenten Suche – unter festen Medien- und Client-Bedingungen und ändern Sie anschließend nur die vermutete begrenzende Ressource.

Einen Endpunkt und eine reproduzierbare Ausgangsbasis festlegen

Beginnen Sie damit, den Endpunkt anhand beobachtbarer Kriterien zu benennen. „Immich ist langsam“ lässt sich nicht testen, „dieselben zwanzig Miniaturbilder der Zeitleiste werden nach einem Neustart in vier Sekunden angezeigt“ dagegen schon. Halten Sie Client, Netzwerkpfad, Konto, Fotosatz und Startbedingung konstant, damit sich spätere Durchläufe nur in einer beabsichtigten Variable unterscheiden.

Das Datenpfadmodell von Immich zeigt, dass Upload, Verarbeitung, Datenbankauswahl und Medienbereitstellung unterschiedliche Abhängigkeiten durchlaufen. Bei einem Test der Suchauswahl sollten Sie die Zeit bis zur Ergebnisliste getrennt von der Bilddarstellung messen; andernfalls wird eine schnelle Abfrage gefolgt von langsamen Dateizugriffen als eine einzige undifferenzierte Verzögerung erfasst.

Führen Sie die Ausgangsmessung mindestens dreimal durch und bewahren Sie sowohl den Median als auch das langsamste aussagekräftige Perzentil auf. Protokollieren Sie Warteschlangentiefe, CPU-Auslastung je Container, Speicherdruck, Swap-Aktivität, Netzwerkdurchsatz und Neuübertragungen, Festplattenlatenz sowie I/O-Warteschlangentiefe. Eine Engpassbehauptung muss das Signal der Ressource mit der Verzögerung des Endpunkts in Einklang bringen.

CPU-Sättigung von Speicherdruck unterscheiden

Bei einem CPU-gebundenen Durchlauf warten ausführbare Aufgaben auf Prozessorzeit; daher sollte die Latenz des Endpunkts mit einer anhaltenden Auslastung der Kerne oder einer Drosselung korrelieren. Bei einem speichergebundenen Durchlauf können stattdessen Rückgewinnung, Swap, Container-Abbrüche oder wiederholtes Laden von Modellen auftreten. Beides kann CPU-Diagramme ausgelastet erscheinen lassen, doch die Eingriffe führen zu unterschiedlichen Reaktionen.

Ein aktueller unabhängiger Ressourcenleitfaden zu Immich schlüsselt die Nutzung für Server, PostgreSQL, Redis und die Komponenten für maschinelles Lernen auf, anstatt den gesamten RAM als eine einzige Anforderung zu behandeln. Diese Betrachtung auf Dienstebene ist wichtig, weil freier Arbeitsspeicher des Hosts neben einem zu knapp bemessenen Containerlimit bestehen kann, während ein großer Dateicache nicht automatisch auf Speichernot hindeutet.

Überprüfen Sie CPU-Druck, indem Sie die Parallelität der Hintergrund-Worker verringern oder mehr CPU zuweisen, während Sie den Speicher konstant halten. Überprüfen Sie Speicherdruck, indem Sie Swap-Aktivität beseitigen oder ein begrenztes Speicherlimit erhöhen, ohne die Anzahl der Worker zu ändern. Verbessert sich der Endpunkt nicht zuverlässig, verwerfen Sie diese Ressource als primäre Begrenzung für diesen Test.

Netzwerkverzögerung von Speicherverzögerung unterscheiden

Netzwerk- und Speichergrenzen treten häufig gemeinsam auf, weil entfernte Medien beide Bereiche durchlaufen. Eine gesättigte Verbindung begrenzt die übertragenen Bytes pro Sekunde, während Speicherkonkurrenz die Abschlusszeit von Lese- oder Schreibvorgängen erhöht, selbst wenn die Verbindung kaum ausgelastet ist. Tests ausschließlich von einem entfernten Client können daher die langsame Dateibereitstellung fälschlich der falschen Schicht zuordnen.

Die SSD-Analyse von Kingston betont Hintergrundaktivitäten, Firmwareverhalten, Caching und Host-Befehle, die die Speicherreaktion über die beworbene sequenzielle Geschwindigkeit hinaus beeinflussen. Bei Immich sind viele kleine Miniaturbild- und Datenbankvorgänge beteiligt, weshalb Latenz und Warteschlangenverhalten aussagekräftiger sind als ein einzelnes Ergebnis zur Bandbreite bei großen Dateien.

Wiederholen Sie den Endpunkt zunächst von einem kabelgebundenen lokalen Client und anschließend über den normalen entfernten Pfad, ohne den Server-Datensatz zu ändern. Lesen Sie separat einen repräsentativen Dateisatz auf dem Host und beobachten Sie die Geräte-Latenz. Eine Verbesserung ausschließlich beim lokalen Client deutet auf den Netzwerkpfad hin; anhaltende Wartezeiten auf dem Host deuten auf den Speicher oder dessen Einbindung hin.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Mit einer Interventionsmatrix jede Ursache bestätigen oder verwerfen

Erstellen Sie vor dem Test vier Zeilen: CPU, Speicher, Netzwerk und Speichergerät. Geben Sie jeder Zeile ein erwartetes Symptom, einen gezielten Eingriff und eine Bedingung zum Verwerfen. So verhindern Sie, dass sich die Diagnose nach dem Eintreffen der Ergebnisse verändert, und machen ein negatives Ergebnis nützlich, statt es zum Anlass zu nehmen, mehrere Upgrades gleichzeitig zu kaufen.

Ein öffentlicher Praxisbericht zu Immich über verzögerte Miniaturbilder trotz beträchtlicher Internetbandbreite zeigt, warum technische Daten allein nicht ausreichen. Entscheidend ist, ob eine gezielte Änderung den gemessenen Endpunkt beeinflusst, während Mediengruppe, Cache-Zustand, Jobs, Client und Anwendungsversion unverändert bleiben.

Akzeptieren Sie CPU nur dann als Ursache, wenn eine Entlastung des Prozessors die Latenz verbessert; Speicher nur, wenn eine Entlastung bei der Rückgewinnung Wirkung zeigt; Netzwerk nur, wenn eine Entlastung des Pfads Wirkung zeigt; und Speicher nur, wenn eine geringere Wartezeit am Gerät oder an der Einbindung Wirkung zeigt. Wenn zwei Eingriffe helfen, wiederholen Sie sie in beiden Reihenfolgen, da der zweite Engpass möglicherweise erst sichtbar wird, nachdem der erste beseitigt wurde.