Welche Abhängigkeiten setzen der tatsächlichen Immich-Leistungsgrenze am häufigsten Grenzen?

Die Leistung von Immich wird in der Regel durch die langsamste aktive Abhängigkeit in einem bestimmten Workflow begrenzt, nicht durch eine dauerhaft festgelegte Hardware-Spezifikation.

Uploads, die intelligente Suche, das Durchsuchen der Zeitleiste und die Videowiedergabe durchlaufen unterschiedliche Kombinationen aus Client, Netzwerk, Server, Datenbank, Workern und Speicher. Die tatsächliche Obergrenze verschiebt sich, wenn sich der Endpunkt oder die Überschneidung mit Hintergrundaufgaben ändert. Eine aussagekräftige Kapazitätsbewertung sollte daher mit einem Pfad statt mit einer Komponentenliste beginnen.

Eine Leistungsobergrenze gehört zu einem Endpunkt

Eine Leistungsobergrenze ist die maximal sinnvolle Rate oder die minimal erreichbare Latenz für eine Operation unter festgelegten Bedingungen. Sie entspricht nicht dem höchsten CPU-Auslastungswert. Die Annahme eines Uploads, die Auswahl eines Suchergebnisses, sichtbare Vorschaubilder und abspielbare Videos haben unterschiedliche Abschlusszeitpunkte und daher unterschiedliche Abhängigkeitsketten.

Der Immich-Datenpfad-Artikel von ZimaSpace unterscheidet zwischen der Annahme von Uploads, der Verarbeitungsbereitschaft, der Auswahl von Suchergebnissen und der Medienbereitstellung. Diese Unterscheidung erklärt, warum die Verbesserung eines Machine-Learning-Workers die Indexierung beschleunigen kann, ohne die Bereitstellung von Vorschaubildern zu verändern, und warum ein schnellerer Netzwerkzugriff eine langsame Datenbankabfrage nicht beheben kann.

Notiere für jede Beschwerde oder jeden Benchmark das Start- und Endereignis, den Client, die Mediengruppe, den Cache-Zustand und die Hintergrundauslastung. Zeichne erst danach die erforderlichen Stufen ein. Die Obergrenze wird durch die Stufe festgelegt, deren Bearbeitungszeit oder Warteschlange verhindert, dass sich der Endpunkt verbessert, wenn vorgelagerte Arbeit schneller eintrifft.

Datenbank- und Warteschlangenzustand begrenzen häufig die Koordination

Die Datenbank wählt Assets aus und erhält Anwendungsbeziehungen, während der Warteschlangenzustand die Hintergrundverarbeitung koordiniert. Ihre Verzögerungen können Suche, Importe oder die Bereitschaft begrenzen, selbst wenn Rechen-Worker noch freie Kapazitäten haben. Umgekehrt kann eine tiefe Warteschlange darauf hindeuten, dass mehr Arbeit eingeht, als die Worker verarbeiten können, und nicht darauf, dass der Warteschlangendienst selbst langsam ist.

Eine tiefgehende Architekturanalyse beschreibt PostgreSQL als Speicher für Benutzer, Assets, Alben und Vektoreinbettungen, während Redis asynchrone Job-Warteschlangen verwaltet. Die Quelle ist eine unabhängige Erklärung einer Bereitstellung; ihr Wert liegt hier in der Trennung der Abhängigkeiten und nicht in einer bestimmten Ressourcenzahl.

Beobachte Datenbankantwortzeit, Verbindungswartezeiten, Warteschlangentiefe und abgeschlossene Jobs pro Minute gemeinsam. Wenn die Warteschlangentiefe steigt, der Worker-Durchsatz unverändert bleibt und die Datenbankzeiten stabil sind, sind die Worker wahrscheinlich der begrenzende Faktor. Wenn jede Stufe im Zusammenhang mit Datenbankwartezeiten pausiert, kann zusätzliche Worker-Konkurrenz die Obergrenze verschlechtern.

Speicher, Arbeitsspeicher und Rechenleistung tauschen den Engpass untereinander aus

Der Arbeitsspeicher kann Datenbankseiten, Vorschaubilder und Modelle in Prozessornähe halten. Passt der Arbeitssatz nicht mehr hinein, gelangt die Speicherlatenz in Anfragen, die zuvor mit Arbeitsspeichergeschwindigkeit bearbeitet wurden. Bei neuen Importen können stattdessen rechenintensive Aufgaben für Vorschaubilder, Videos und maschinelles Lernen dominieren. Die begrenzende Abhängigkeit ändert sich je nach Zustand und Arbeitslast.

Eine Analyse zum Selbsthosting von Immich unterscheidet den moderaten Bedarf von Anwendung und Datenbank vom höheren Speicherbedarf des maschinellen Lernens und weist auf die Auswirkungen des Ladens von Modellen hin. Die konkreten Zahlen variieren je nach Version und Modell, aber die Abhängigkeit bleibt dieselbe: Die gesamte RAM-Menge zeigt nicht, welcher Dienst seinen Arbeitssatz verliert.

Vergleiche Kaltstart-, Warmstart- und Dauerphasen. Ein großer Zugewinn von kalt zu warm weist auf das Laden von Modellen oder Caches hin; hohe Gerätelatenz bei umfangreichen Abfragen deutet auf fehlende Arbeitssätze hin; ausgelastete Rechenleistung bei stabiler E/A deutet auf Verarbeitung hin. Wiederhole nach der Änderung einer einzelnen Begrenzung den vollständigen Pfad, da nun die nächste Stufe dominieren kann.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Erstelle eine Zuordnung von Endpunkten zu Abhängigkeiten

Erstelle Zeilen für die Annahme von Uploads, die Antwort auf ein Suchergebnis, das letzte sichtbare Vorschaubild der Zeitleiste und den Videostart. Füge Spalten für die Vorbereitung durch den Client, die Netzwerkübertragung, die Anwendungsverarbeitung, Datenbank- oder Warteschlangenarbeit, die Verarbeitung durch Worker, den Speicherzugriff und die Client-Dekodierung hinzu. Kennzeichne nicht verwendete Stufen, statt jede Komponente jedem Endpunkt zuzuordnen.

Ein Community-Bericht über das Auslagern der Vorschaubildgenerierung für eine zwei Terabyte große Familienbibliothek verdeutlicht, wie wichtig es ist, die Verarbeitungskapazität von der NAS-Speicherkapazität zu unterscheiden. Er beweist nicht, dass Auslagern immer erforderlich ist, sondern identifiziert einen bestimmten Worker-Pfad, der bei einem großen Import dominieren kann.

Miss einen repräsentativen Durchlauf und ordne nur die beobachteten Wartezeiten. Schlage für die führende Stufe eine Maßnahme und eine Bedingung vor, unter der sie verworfen wird. Verbessert sich der Endpunkt, aktualisiere die Zuordnung, weil sich die Obergrenze verschoben hat. Andernfalls verwerfe diese Hypothese. So entsteht eine Beweiskette statt einer Einkaufsliste.