Welches Speicherlimit solltest du für Immich festlegen?

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.

What Memory Limit Should You Set for Immich? - Zima Store Online

Setzen Sie kein einheitliches Immich-Speicherlimit anhand einer pauschalen GB-Zahl fest. Ein RAM-Ziel auf Host-Ebene und eine Begrenzung pro Container lösen unterschiedliche Probleme: Der Host muss den gesamten Stack unterstützen, während ein Containerlimit den Host schützen sollte, ohne eine legitime Immich-Arbeitslast abzuwürgen.

Das Durchsuchen einer verarbeiteten Bibliothek kann unauffällig wirken, während ein Kaltstart des maschinellen Lernens, ein großer Import, die Thumbnail-Erstellung, die Gesichtsanalyse oder die Videoverarbeitung deutlich mehr Speicher verbraucht. Messen Sie die anspruchsvollste Arbeitslast, die Sie tatsächlich benötigen, halten Sie Reserven für PostgreSQL und das Betriebssystem frei und betrachten Sie wiederholte OOM-Kills als fehlgeschlagenes Limit statt als normale Drosselung.

Messen Sie den Speicherdruck, bevor Sie das Limit festlegen

Erfassen Sie den Speicherverbrauch in drei Zuständen: beim ruhigen Durchsuchen, bei einem repräsentativen täglichen Upload und bei der anspruchsvollsten geplanten Hintergrundarbeitslast. Erfassen Sie die Containernutzung, den verfügbaren Speicher des Hosts, die Swap-Aktivität, OOM-Ereignisse und ob die Aufgaben weiterhin Fortschritte machen. Ein einzelner Spitzenwert aus docker stats reicht nicht aus, da die Linux-Speicherabrechnung mehrere Speicherarten mit unterschiedlichem Rückgewinnungsverhalten umfasst.

Eine hilfreiche Aufschlüsselung des Docker-cgroup-Speichers unterscheidet zwischen anonymem Speicher, dateigestütztem Cache und Slab, anstatt die Rohsumme als gleichermaßen gefährlich zu behandeln. Stabiler Dateicache bei ausreichenden Host-Reserven unterscheidet sich von stetig wachsendem anonymem Speicher, Swap-Druck oder einem cgroup-OOM-Zähler, der während desselben Immich-Jobs ansteigt.

Schließen Sie diese Phase ab, wenn Sie einen reproduzierbaren Höchststand ermitteln und erklären können, ob er überwiegend aus zurückgewinnbarem Cache oder aktivem Arbeitsspeicher besteht. Wenn der Verbrauch bei einer unveränderten Arbeitslast weiter ansteigt, ein Container wiederholt per OOM beendet wird oder der Host stark zu swappen beginnt, legen Sie die Größe nicht anhand dieses Durchlaufs fest, sondern untersuchen Sie zuerst das anomale Wachstum.

Richten Sie die Begrenzung an der anspruchsvollsten gültigen Immich-Arbeitslast aus

Wählen Sie die Arbeitslast, die auch nach Anwendung des Limits unterstützt werden muss. Für einen Haushalt kann das bedeuten, dass vier Smartphones gleichzeitig hochladen, während Smart Search und Gesichtserkennung noch aufgeholt werden; für einen anderen kann es ein großer Erstimport mit anschließendem normalen Durchsuchen sein. Halten Sie Datensatz, Modelle, Einstellungen zur Parallelität und andere Container während der Messung unverändert, damit das Limit einem klar definierten Serviceversprechen entspricht.

Setzen Sie die harte Begrenzung oberhalb des beobachteten nicht zurückgewinnbaren Spitzenwerts an und lassen Sie ausreichend messbaren Spielraum für kurze Spitzen, während Sie Speicher für PostgreSQL, den Dateisystem-Cache, die Container-Laufzeitumgebung und unabhängige Dienste bewahren. Die zugehörige ZimaSpace-Checkliste zu Warnzeichen bei Ressourcenproblemen durch lokale KI ist hilfreich, da Hitze, Swapping und plötzliche Neustarts eine Belastung auf Host-Ebene zeigen können, die ein reines Immich-Diagramm übersieht. Interpretieren Sie nicht, dass „der Container einmal das Limit erreicht hat“, als Beweis dafür, dass mehr RAM erforderlich ist. Entscheidend ist die Fehlergrenze: Wird dieselbe gültige Arbeitslast erheblich langsamer, gehen Aufgaben verloren, wird dauerhaft geswappt oder tritt ein OOM-Kill auf? Umgekehrt ist ein Limit zu großzügig, wenn Immich die Datenbank oder den Host verdrängen kann, bevor die eigene cgroup zur Begrenzung wird.

Reduzieren Sie die Arbeitslast, bevor Sie das Limit wegen anomalen Wachstums erhöhen

Wenn das vorgeschlagene Limit nur bei einer bestimmten Art von Hintergrundarbeit versagt, reduzieren Sie die Parallelität dieses Jobs oder isolieren Sie die betreffende Phase, bevor Sie das Limit erhöhen. Maschinelles Lernen, Thumbnail-Erstellung, Videoverarbeitung und Datenbankarbeit können unterschiedliche Speicherprofile haben. Ein kleineres aktives Batch kann langsamer fertig werden, während die Haushaltsoberfläche reaktionsfähig und der Host wiederherstellbar bleibt.

Auch versionsabhängige Fehler spielen eine Rolle. Ein Immich-Speicherbericht zu v3.0.3 beschrieb, wie ein Worker für maschinelles Lernen weiter wuchs, bis ein cgroup-Limit nach einer fehlerhaften Bedingung im Zusammenhang mit der Locale einen OOM auslöste. Dieser Fall definiert nicht den normalen RAM-Bedarf von Immich; er zeigt, warum ungeklärtes Wachstum zunächst als Software- oder Konfigurationsproblem behandelt werden sollte, bevor das Host-Budget dauerhaft erhöht wird.

Führen Sie die gleiche Arbeitslast erneut aus, nachdem Sie eine Variable zur Parallelität, ein Modell oder eine Version geändert haben. Behalten Sie die Änderung nur bei, wenn sich sowohl das Speichermuster als auch der ursprüngliche Job in der erwarteten Richtung verbessern. Wenn der Speicher weiterhin steigt, ohne ein stabiles Plateau zu erreichen, sichern Sie Protokolle und Versionsdetails und eskalieren Sie das Problem, statt das harte Limit in eine immer größere Zahl umzuwandeln.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Überprüfen Sie das Limit nach einem Kaltstart und einem ausgelasteten Zyklus

Starten Sie den Host neu, damit Caches und im Speicher befindliche Modelle von einem bekannten kalten Ausgangszustand beginnen. Führen Sie die normalen Anmelde- und Browsing-Prüfungen sowie anschließend den repräsentativen Upload und die Hintergrundarbeitslast durch. Erfassen Sie den Spitzenwert des anonymen Speichers, den Cache, den Swap, OOM-Zähler, die Datenbankreaktionszeit, die Zeit zum Abarbeiten der Warteschlange und ob ein anderer wichtiger Container reaktionsfähig bleibt.

Ein bestandendes Limit übersteht sowohl den Kaltstart als auch den ausgelastetsten normalen Zyklus ohne OOM-Kills, anhaltendes Swap-Thrashing, wiederholte Containerneustarts oder eine Warteschlange, die nicht weiter abgearbeitet wird. Außerdem sollte es genügend Host-Reserven für Wiederherstellungsaufgaben wie einen Datenbank-Dump oder eine administrative Anmeldung lassen, während Immich ausgelastet ist.

Wenn nur ein künstlicher Stresstest fehlschlägt, während jede definierte Haushaltsarbeitslast erfolgreich ist, dokumentieren Sie die akzeptierte Grenze, statt für ein Szenario RAM zu kaufen, das Sie nicht benötigen.

Wenn eine reale Arbeitslast nicht erfolgreich abgeschlossen werden kann, ohne den Host zu erschöpfen, reduzieren Sie die Parallelität, isolieren Sie das maschinelle Lernen, erweitern Sie den Speicher oder verschieben Sie konkurrierende Dienste. Wiederholen Sie anschließend dieselbe Validierung, bevor Sie das neue Limit als sicher erklären.