Wie groß kann eine Jellyfin-Mediathek auf einem einzelnen Host werden?

Es gibt keine nützliche allgemeingültige Obergrenze für die Anzahl der Jellyfin-Elemente, anhand derer sich feststellen lässt, wann ein Host „voll“ ist. Die praktische Grenze ist erreicht, wenn Ihre Datenbank, der Arbeitsspeicher, der Speicherplatz, geplante Aufgaben oder die gleichzeitige Wiedergabe Ihr Ziel für die Antwortzeit nicht mehr erfüllen können.

Zwei Bibliotheken mit derselben Anzahl an Filmen können einen Server sehr unterschiedlich belasten, da sich Metadatendichte, Kapitelbilder, Trickplay-Daten, Netzwerkspeicher, Client-Mix und Transcodierungsbedarf unterscheiden. Messen Sie den Host unter Ihrer tatsächlichen Arbeitslast und definieren Sie einen Grenzwert, den Sie nach jeder größeren Bibliothekserweiterung erneut überprüfen können.

Beginnen Sie mit dem Datenbankumfang, nicht mit der Anzahl der Mediendateien

Jellyfin speichert den Bibliotheksstatus in seiner Datenbank, während die Mediendateien im Dateisystem verbleiben. Wenn der Katalog wächst, ist daher die Größe und das Verhalten des Jellyfin-Datensatzes die aussagekräftigere erste Kennzahl als die Gesamtkapazität der Filmdateien.

Die Speicherdokumentation von Jellyfin weist darauf hin, dass eine Datenbank für eine mittelgroße Bibliothek ungefähr 10 bis 100 GB erreichen kann, und empfiehlt, die Datenbank auf lokalem Speicher statt auf einer Netzwerkfreigabe abzulegen. Hinweise zur Datenbankspeicherung

Erfassen Sie die Datenbankgröße, den freien Speicherplatz auf dem Datenvolume und die Zeit, die zum Öffnen großer Bibliotheksansichten oder zum Suchen nach dem Aufwärmen des Caches benötigt wird. Bleiben diese Werte stabil, während die Medienkapazität wächst, hat die reine Mediengröße die Anwendung noch nicht über die Grenze eines einzelnen Hosts hinausgebracht.

Messen Sie den verfügbaren Arbeitsspeicher nach dem Aufwärmen der Datenbank

Das Speicherverhalten ist bei aktuellen Jellyfin-Versionen wichtiger, da der Server große Mengen an Datenbankdaten im Arbeitsspeicher halten kann, um Festplattenzugriffe zu reduzieren. Ein Host, der bei einem kleineren Katalog noch ausreichend dimensioniert wirkte, kann daher nach dem Wachstum der Bibliothek einen höheren konstanten RAM-Verbrauch aufweisen.

Die Versionshinweise zu Jellyfin 10.11 erklären, dass die Datenbank-Engine Metadaten aggressiv im Arbeitsspeicher zwischenspeichert und den Speicher bis zur Größe der Bibliotheksdatenbank nutzen kann, ihn aber freigibt, wenn andere Prozesse ihn benötigen. Datenbank-Caching im Arbeitsspeicher

Beobachten Sie den verfügbaren Arbeitsspeicher und die Swap-Aktivität, nachdem das normale Browsen den Cache aufgewärmt hat. Ein hoher Cache-Verbrauch allein ist kein Warnsignal. Kritisch sind anhaltender Speicherdruck, Auslagerungen oder eine Latenz, die auftritt, wenn Jellyfin mit anderen Containern konkurriert, und verschwindet, sobald diese Konkurrenz wegfällt.

Erfassen Sie die Dauer der mit der Bibliothek wachsenden Hintergrundaufgaben

Bibliotheksscans, Metadatenaktualisierungen, Bilderstellung, Untertitelverarbeitung und andere geplante Aufgaben können zur ersten Skalierungsgrenze werden, selbst wenn die Wiedergabe weiterhin reibungslos funktioniert. Messen Sie, wie lange diese Aufgaben laufen und ob sie sich mit den Zeiten überschneiden, in denen der Server tatsächlich genutzt wird.

Die Extraktion von Kapitelbildern ist ein Beispiel für einen von Jellyfin dokumentierten direkten Skalierungsaufwand: Wird die Extraktion während eines Bibliotheksscans aktiviert, können sich Scans deutlich verlangsamen, insbesondere bei großen Bibliotheken. Kosten eines Kapitelbild-Scans

Wenn ein vollständiger Scan inzwischen den Großteil des Wartungsfensters beansprucht, reduzieren Sie zunächst unnötige Arbeiten oder verschieben Sie aufwendige Aufgaben in Zeiten außerhalb der Spitzenlast. Ein längerer Scan bedeutet nicht automatisch, dass der Host zu schwach ist. Er wird zum Kapazitätsproblem, wenn die Wartung wiederholt mit der interaktiven Nutzung kollidiert oder nie zuverlässig abgeschlossen wird.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Trennen Sie die Bibliotheksgröße von der Transcodierungskapazität

Ein riesiger Katalog macht einen Direct-Play-Stream nicht zwangsläufig aufwendig, während ein kleiner Katalog eine CPU überlasten kann, wenn mehrere inkompatible Clients Videotranscodierung anfordern. Behandeln Sie die Kataloggröße und die Wiedergabekonvertierung als getrennte Kapazitätstests.

Führen Sie mit dem tatsächlich verwendeten Client-Mix einen wiederholbaren Wiedergabetest durch: einen Direct-Play-Stream, eine typische Transcodierung und anschließend die erwartete maximale Anzahl gleichzeitiger Streams. Wenn der Katalog wächst, diese Wiedergabetests aber unverändert bleiben, haben Sie aufgrund der Bibliotheksgröße keine Transcodierungsgrenze erreicht.

Wenn die CPU-Auslastung nur während der Transcodierung an ihre Grenze stößt, optimieren Sie Codecs, Hardwarebeschleunigung oder die Client-Kompatibilität, bevor Sie die Datenbank dafür verantwortlich machen. Der Leitfaden zur Hardwarebeschleunigung ist der sinnvollere nächste Schritt, als eine gesunde Metadatendatenbank auf einen zweiten Server zu verschieben.

Prüfen Sie die Speicherlatenz und die Verfügbarkeit der Medien während der Scanlast

Große Bibliotheken erstrecken sich häufig über mehrere Laufwerke oder ein NAS, sodass der Zugriffspfad zu den Medien zum begrenzenden Faktor werden kann. Vergleichen Sie interaktives Browsen und die Wiedergabe mit und ohne laufenden Bibliotheksscan und beobachten Sie die Laufzeit der Festplattenwarteschlange oder die Latenz der Netzwerkfreigabe auf dem Medienpfad.

Jellyfin empfiehlt, Samba- oder NFS-Speicher direkt in das Betriebssystem einzubinden, und warnt davor, dass geplante Wartungsaufgaben Bibliothekselemente entfernen können, wenn der Speicher beim Ausführen einer Aufgabe nicht verfügbar ist. Hinweise zu Netzwerkspeicher und Wartung

Wenn die Datenbank schnell ist, aber Medienverzeichnisse zeitweise verschwinden oder Metadatenscans an einer langsamen Freigabe hängen, wird zusätzliche CPU-Leistung den eigentlichen Engpass nicht beheben. Beheben Sie zuerst die Zuverlässigkeit der Einbindung, die Speicherlatenz oder die Aufgabenplanung und wiederholen Sie anschließend denselben Benchmark.

Definieren Sie Ihr eigenes Limit für einen einzelnen Host mit einem wiederholbaren Benchmark

Erstellen Sie vor der nächsten Bibliothekserweiterung eine kleine Übersicht: Suchlatenz bei aufgewärmtem Cache, Zeit zum Öffnen einer großen Sammlung, Dauer des vollständigen Scans, Datenbankgröße, verfügbarer RAM, maximale Speicherlatenz und ein repräsentativer Test für die gleichzeitige Wiedergabe. Verwenden Sie jedes Mal dieselben Messwerte.

Ein praktischer Workflow für ein Medienzentrum zu Hause trennt die Medienspeicherung bereits von der Jellyfin-Anwendungsebene. Behalten Sie diese Trennung auch in Ihrem Benchmark bei, damit Sie erkennen, ob eine Verlangsamung vom Host, vom Speicherpfad oder von den Clients verursacht wird.

Betrachten Sie den einzelnen Host erst dann als überlastet, wenn ein gemessenes Ziel trotz risikoarmer Optimierungen wiederholt verfehlt wird: Interaktive Anfragen bleiben langsam, Scans können im Wartungsfenster nicht abgeschlossen werden, Speicherdruck führt zu Auslagerungen, die Speicherlatenz lässt sich nicht isolieren oder erforderliche Transcodierungen überschreiten die verfügbare Rechenleistung. Dann zeigt Ihnen die Evidenz, welche Ressource erweitert werden muss, statt Sie zu einer willkürlichen Obergrenze für die Elementanzahl zu zwingen.