Immich auf einem Multi-App-Heimserver: Wie gemeinsam genutzte Ressourcen die Ergebnisse verändern

Die Ergebnisse von Immich ändern sich auf einem Server mit mehreren Apps, weil Container trotz getrennter Prozessgrenzen begrenzte CPU-, Speicher-, Speicherplatz- und Netzwerkkapazitäten gemeinsam nutzen.

Eine Fotosuche kann mittags schnell und während der Sicherung, des Scans oder der Transkodierung einer anderen Anwendung langsam sein. Die Immich-Konfiguration hat sich nicht geändert, aber das verfügbare Ressourcenbudget und die Cache-Inhalte schon. Eine hilfreiche Erklärung muss daher die gesamte Auslastung des Hosts berücksichtigen.

Container trennen Prozesse, nicht die physische Kapazität

Container stellen Namespaces und steuerbare Limits bereit, werden letztlich aber auf denselben Prozessoren ausgeführt und greifen normalerweise auf denselben Speichercontroller, dieselben Laufwerke und Netzwerkschnittstellen zu. Ein Immich-Dienst kann innerhalb seines eigenen Limits bleiben und trotzdem auf einem gemeinsam genutzten physischen Gerät oder im Kernel-Scheduler hinter unabhängigen Aufgaben warten.

Ein Erfahrungsbericht zu Immich mit mehreren Containern beschreibt einen stromsparenden Host, auf dem Dutzende Container mit üblicherweise moderater CPU-Auslastung laufen. Das garantiert anderswo keine identischen Ergebnisse; es zeigt jedoch, warum die Anzahl der Dienste allein wenig aussagekräftig ist und warum tatsächlich gleichzeitig laufende Aufgaben auf Host-Ebene beobachtet werden müssen.

Erfasse alle geplanten und schubweise auftretenden Nachbarn: Sicherungen, Medienscans, Downloads, Datenbanken und Videotranskodierungen. Protokolliere deren Startzeiten zusammen mit der Immich-Latenz. Eine Korrelation beweist keine Ursache, aber wiederholte Übereinstimmungen zeigen, dass ein kontrolliertes Pausieren oder eine Änderung der Zeitplanung als Experiment die vermutete Beeinträchtigung prüfen kann.

Speicherkonkurrenz verändert die Cache-Residentz

Immich profitiert davon, wenn häufig verwendete Datenbankseiten, Vorschaubilder und Modelldaten im Speicher resident bleiben. Ein benachbarter Dienst, der seinen Arbeitssatz vergrößert, kann diese Seiten verdrängen, ohne dass ein Speicherfehler auftritt. Die nächste Anfrage verursacht dann Speicher- oder Modell-Ladevorgänge, die nicht anfielen, solange die Daten im Cache lagen.

Die Diskussion über Server-Speicher von Kingston erklärt, dass eine ausreichende Kapazität die Abhängigkeit speicherintensiver Anwendungen von langsamerem Speicher reduziert. Auf diesen Fall übertragen bedeutet das nicht, dass jeder Heimserver Enterprise-Speicher benötigt. Entscheidend ist vielmehr, dass ein verlorener Cache eine scheinbar identische Immich-Anfrage in eine andere physische Arbeitslast verwandeln kann.

Vergleiche die Aktivitäten des Seiten-Caches, Swap, Major Page Faults und Lesezugriffe auf den Speicher, bevor und nachdem der Nachbar startet. Wenn das Pausieren des Dienstes das Verhalten bei warmen Anfragen wiederherstellt, ohne Immich zu verändern, deutet das auf die Speicher-Residentz als Ursache hin. Ein hoher Prozentsatz belegten RAMs allein reicht als Indikator nicht aus, weil gesundes Dateisystem-Caching absichtlich ansonsten ungenutzten Speicher verwendet.

Speicherwarteschlangen koppeln unabhängige Dienste

Eine Sicherung kann große Dateien übertragen, während Immich kleine Datenbank- und Vorschaubildvorgänge ausführt. Selbst wenn die Gesamtbandbreite unter dem vom Laufwerk angegebenen Maximum bleibt, kann die Warteschlange die Abschlusszeit latenzempfindlicher Anfragen erhöhen. Netzwerkgebundener Speicher fügt derselben Kette der Konkurrenz einen weiteren Scheduler und Netzwerkpfad hinzu.

Der Artikel zum Immich-Datenpfad von ZimaSpace zeigt, dass die Auswahl der Suchergebnisse und die Anzeige der Medien getrennte Schritte mit unterschiedlichen Abhängigkeiten sind. Diese Unterscheidung hilft dabei, eine Kopplung über den Speicher zu erkennen: Schnelle Ergebniskennungen mit anschließend verzögerten Vorschaubildern deuten auf einen späteren Abschnitt des Pfads hin als eine Datenbankauswahl, die selbst langsam ist.

Miss die Gerätelatenz und die Warteschlangentiefe pro Einhängepunkt, während du dieselbe Anfrage reproduzierst. Pausiere nur den mutmaßlich I/O-intensiven Nachbardienst und wiederhole den Test, nachdem sich die Caches stabilisiert haben. Wenn die Verbesserung mehrere abwechselnde Durchläufe übersteht, sind eine Anpassung der Zeitplanung oder eine Trennung von Speicherressourcen gerechtfertigt. Andernfalls sollten CPU-, Speicher- oder Netzwerk-Hypothesen erneut geprüft werden.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verwende einen Isolierungstest mit Pausieren und Wiederholen

Wähle einen festen Endpunkt, etwa das Laden desselben Zeitachsenabschnitts oder die Ausführung einer bekannten intelligenten Suche, und definiere Bedingungen für einen kalten oder warmen Cache. Führe drei Durchläufe mit dem vollständigen Dienstmix aus. Pausiere anschließend einen möglichen Nachbardienst, ohne Immich neu zu starten, und wiederhole dieselbe Client-Sequenz und denselben Beobachtungszeitraum.

Ein Bericht über starke Konkurrenz durch Immich während der Verarbeitung nach einem Update beschreibt, dass ein anderer Fotodienst keine Uploads mehr ausführen konnte, während der Host ausgelastet war. Das ist eine einzelne Konfiguration und keine allgemeingültige Grenze, zeigt aber, dass eine gesunde Hintergrundwarteschlange genügend gemeinsam genutzte Kapazität verbrauchen kann, um einen anderen interaktiven Dienst zu beeinträchtigen.

Akzeptiere eine Beeinträchtigung nur dann als Ursache, wenn das Pausieren eine wiederholbare Änderung der Latenz bewirkt und die Wartezeit auf der betreffenden Ressource gleichzeitig sinkt. Teste anschließend eine gezielte Maßnahme: geringere Parallelität, ein Zeitfenster, ein CPU-Kontingent, eine Speicherreservierung oder getrennten Speicher. Bewahre die Einstellungen für einen Rollback auf, da die Isolierung eines Nachbarn ein zweites Limit sichtbar machen kann.