Welches Speicherlimit sollten Sie für Jellyfin festlegen?
Wählen Sie kein universelles Speicherlimit für Jellyfin. Beginnen Sie mit einer gemessenen Arbeitslast, reservieren Sie Speicher für den Host und benachbarte Container und setzen Sie erst dann eine harte Obergrenze, wenn Sie die tatsächlichen Spitzenwerte beobachtet haben.
Wächst Ihr Container, bis der Host auf Swap ausweicht, oder verursacht ein niedriges Limit wiederholte OOM-Kills? Messen Sie die Auslastung im Leerlauf, Bibliotheksscans, Metadatenverarbeitung, gleichzeitige Transkodierungen und den für Docker oder die VM verfügbaren Speicher, bevor Sie das Limit ändern. Ein Limit ist nur dann sicher, wenn die ursprüngliche Arbeitslast weiterhin abgeschlossen wird und dem Host noch ausreichende Reserven zur Wiederherstellung bleiben.
Normales Cache-Wachstum von Speicherknappheit im residenten Speicher unterscheiden
Vergleichen Sie zunächst den RSS-Speicher des Containers, den Cache, den Swap und den freien Host-Speicher im Leerlauf sowie während des anspruchsvollsten wiederholbaren Vorgangs. Der Dateisystem-Cache kann groß erscheinen, ohne dass ein Speicherleck vorliegt, während steigender residenter Speicher zusammen mit OOM-Ereignissen auf eine tatsächliche Einschränkung hindeutet.
Eine einfache Docker-Bereitstellung von Jellyfin beginnt häufig mit einigen Gigabytes und benötigt für die Transkodierung mehr, doch der korrekte Wert hängt von der Arbeitslast ab (arbeitslastbasierte Speichergrundlage).
Bleibt der RSS-Speicher konstant, während der Cache wächst, und verfügt der Host über freigebbaren Speicher, sollten Sie beobachten, statt das Limit zu verschärfen. Steigt der RSS-Speicher zusammen mit Swap-Nutzung oder OOM-Kill-Meldungen, fahren Sie mit den Transkodierungs- und Bibliothekstests fort.
Testen Sie das Limit unter dem auslösenden Fehlerzustand
Führen Sie einen Bibliotheksscan, eine repräsentative Transkodierung und die erwartete Anzahl gleichzeitiger Streams durch. Zeichnen Sie dabei die Speichernutzung der cgroups, Speicherereignisse, Swap-Nutzung und die Auslastung des Hosts auf. Ändern Sie zwischen den Durchläufen ausschließlich das Speicherlimit.
Ein Limit, das bei der Wiedergabe im Leerlauf ausreicht, aber bei Untertiteln, HDR-Konvertierung oder der Indizierung versagt, ist keine gültige Produktionseinstellung. Notieren Sie, welcher Auslöser den Fehler verursacht hat, damit Sie das Limit nicht wegen eines unabhängigen Engpasses erhöhen.
Wird der Container beendet, erhöhen Sie das Limit erst, nachdem Sie unnötigen Transkodierungs-Cache reduziert oder schwere Aufgaben getrennt haben. Wechselt der Host selbst auf Swap, verringern Sie die Parallelität oder verschieben Sie eine Aufgabe. Jellyfin den gesamten verbleibenden RAM zu geben, verlagert den Fehler lediglich auf einen anderen Dienst.
Eine Abbruchgrenze festlegen und die dauerhafte Übernahme prüfen
Setzen Sie eine Warnung unterhalb des harten Limits und lassen Sie ausreichend Speicher für den Host, Speicherdienste und einen sauberen Neustart frei. Eine harte Obergrenze sollte den Host schützen und nicht einen unbeschränkten Prozess oder einen zu klein dimensionierten Rechner verdecken.
Stoppen Sie den Container nach einer Änderung des Limits einmal, erstellen Sie ihn neu und wiederholen Sie anschließend den ursprünglichen Scan sowie den Wiedergabetest, der den Fehler auslöst. Prüfen Sie, ob das konfigurierte Limit nach der Neuerstellung weiterhin aktiv ist und die Datenbank beschreibbar bleibt.
Beenden Sie die Optimierung und eskalieren Sie das Problem, wenn trotz eines Limits, das keine Host-Reserve lässt, weiterhin OOM-Ereignisse auftreten, die Datenbank beschädigt wird oder der Prozess ohne reproduzierbare Arbeitslast weiter wächst. Sichern Sie die Protokolle und die zuletzt bekannte funktionierende Konfiguration, bevor Sie eine größere Änderung vornehmen.
Die Spitzenlast bei der Wiedergabe nach einem Kaltstart erneut prüfen
Starten Sie den Host neu, warten Sie, bis Speichereinbindungen und benachbarte Container bereit sind, und reproduzieren Sie dieselbe Mischung aus Streams mehrerer Benutzer, durch die das Limit ursprünglich überschritten wurde. Validieren Sie nicht nur anhand eines Dashboards im Leerlauf oder einer einzelnen Direct-Play-Sitzung.
Die Wiederherstellung ist bestätigt, wenn die Wiedergabe stabil bleibt, kein Swap-Sturm auftritt, der Container unterhalb seines Limits bleibt und eine frische Sicherung oder ein Neustart ohne speicherbezogene Fehler abgeschlossen wird. Vergleichen Sie das Ergebnis mit der vor der Optimierung aufgezeichneten Grundlage.
Behalten Sie die Einstellung bei, wenn die Spitzenlast mit messbarer Host-Reserve erfolgreich bewältigt wird. Tritt der Fehler erst auf, nachdem ein anderer Container gestartet wurde, teilen Sie das Ressourcenbudget auf oder planen Sie die konkurrierende Aufgabe neu, statt das Jellyfin-Limit erneut zu erhöhen.
Empfohlene Produkte
Support & Tipps
Mehr zum Lesen
So optimieren Sie Jellyfin-Datenbankverbindungen für parallel ausgeführte Container
Beginnen Sie mit einem einzigen Datenbankbesitzer und beobachten Sie das Sperrverhalten von SQLite. Fügen Sie ein anderes Backend erst hinzu, wenn Parallelität und Wiederherstellung...
So verhinderst du doppelte Jobs oder Importe in Jellyfin
Doppelte Arbeit entsteht meist durch überlappende Scheduler oder mehrere Schreibprozesse. Bestimme eine verantwortliche Person, einen einzigen Ablauf und eine einzige Abschlussprüfung.
So reparieren Sie Jellyfin, nachdem das Datenbank-Volume vollgelaufen ist
Schreibvorgänge stoppen, die Datenbank- und WAL-Dateien bewahren, Speicherplatz freigeben, ohne den Zustand blind zu löschen, und anschließend die Integrität sowie die ursprüngliche Arbeitslast überprüfen.
