Wie viel CPU-Reserve sollten Sie für Spitzenlasten bei Jellyfin einplanen?
Es gibt keinen universellen Prozentsatz für CPU-Reserven bei Jellyfin, da Direct Play, Hardware-Transkodierung, das Einbrennen von Untertiteln, Software-Fallbacks, Bibliotheksaufgaben und benachbarte Container die CPU sehr unterschiedlich beanspruchen.
Für einen gemischten Heimserver ist es ein sinnvoller Ausgangspunkt, während der stärksten normalen Dauerbelastung insgesamt etwa 20–30 % CPU-Auslastung frei zu halten – dies ist jedoch keine Jellyfin-Anforderung. Entscheidend ist, dass kurze Lastspitzen keine Warteschlangen verursachen, die Transkodierung bei Bedarf sicher schneller als in Echtzeit bleibt, die Auslastung einzelner Kerne kontrolliert wird und die Latenz interaktiver Aufgaben stabil bleibt, wenn sich normale Hintergrundarbeiten überschneiden.
Die schlimmste normale Kombination messen, nicht ein Leerlauf-Dashboard
Stelle die Spitzenlast nach, die im Haushalt tatsächlich zu erwarten ist: den am wenigsten kompatiblen Client, den erforderlichen Untertitel- oder HDR-Pfad, die erwartete Anzahl gleichzeitiger Sitzungen sowie einen normalen Hintergrundjob oder benachbarten Container, der sich überschneiden kann. Ein künstlicher Belastungstest ist nur dann nützlich, wenn diese Last tatsächlich auftreten kann.
Die CPU-Auslastung allein zeigt nicht, ob Aufgaben warten. Die Methode „Auslastung, Sättigung und Fehler“ prüft sowohl, wie stark eine Ressource ausgelastet ist, als auch, ob sich Anforderungen dahinter in einer Warteschlange sammeln. Kombiniere bei Jellyfin den CPU-Prozentsatz mit Last oder Druck, ausführbaren Aufgaben, der Auslastung einzelner Kerne, der Wiedergabelatenz und der Transkodierungsgeschwindigkeit.
Zeichne zunächst einen stabilen Ausgangswert auf und füge dann jeweils eine Sitzung oder einen Hintergrundjob hinzu. Der Bedarf an CPU-Reserve beginnt dort, wo die erste zusätzliche Anforderung eine messbare Warteschlange oder eine verpasste Echtzeitfrist verursacht – nicht dort, wo die CPU-Kurve lediglich hoch aussieht.
Für Software- und Teilbeschleunigungspfade mehr CPU reservieren
Ein Direct-Play-Server kann selbst bei mehreren Zuschauern sehr wenig CPU benötigen. Eine Software-Videotranskodierung kann dagegen den Großteil der verfügbaren Kerne beanspruchen, während bei aktivierter Hardwarebeschleunigung weiterhin Audiokonvertierung, Untertitel-Rendering, Filter, Orchestrierung oder Fallback-Arbeiten auf der CPU verbleiben können.
Die Aufschlüsselung des ZimaSpace-Artikels zum CPU-Bedarf nach tatsächlicher Jellyfin-Arbeitslast ist die relevante Grenze für die Dimensionierung: Die Kernanzahl ist erst dann entscheidend, wenn bekannt ist, welche Verarbeitungsschritte auf der Allzweck-CPU verbleiben.
Wenn eine erforderliche Softwaretranskodierung die CPU bereits nahe an die Sättigung bringt, bietet eine nominelle durchschnittliche Reserve von 10 % keinen verlässlichen Schutz vor einem zweiten Stream, dem Einbrennen von Untertiteln oder einer Hintergrundanalyse. Halte entweder eine größere Reserve vor, verbessere den Beschleunigungspfad, konvertiere anspruchsvolle Medien vorab oder verhindere, dass umfangreiche Hintergrundjobs während der Wiedergabe überlappen.
Die Sättigung einzelner Kerne prüfen, bevor du dem Durchschnitt vertraust
Eine CPU mit acht Kernen kann eine moderate Gesamtauslastung anzeigen, während ein oder zwei Threads voll ausgelastet sind. Das ist relevant, wenn ein Filter, ein Audiopfad, eine Datenbankaufgabe oder ein einzelner, thread-sensitiver Vorgang die für Nutzer sichtbare Latenz bestimmt.
Betrachte neben der Gesamtauslastung auch die Auslastung einzelner Kerne und den CPU-Druck. Die CPU-Druckmetriken unter Linux zeigen, wie viel Zeit Aufgaben wartend auf CPU-Ressourcen blockiert sind. Für die Diagnose von Spitzenlasten ist das hilfreicher als die Auslastung allein. Eine hohe Durchschnittsauslastung bei geringer Warteschlangenbildung kann für Stapelverarbeitung akzeptabel sein, während eine niedrigere Durchschnittsauslastung mit einem gesättigten kritischen Thread zu Rucklern oder einer langsamen Navigation führen kann.
Versuche nicht, einen einzelnen überlasteten Thread zu beheben, indem du viele weitere langsame Kerne anschaffst, ohne zu prüfen, ob die Arbeitslast diese auch nutzen kann. Wenn der Engpass durch einen bestimmten Softwarefilter oder Fallback-Pfad entsteht, kann eine Änderung des Wiedergabepfads mehr effektive Reserve schaffen als ein höherer aggregierter Benchmark-Wert.
Transkodierungsgeschwindigkeit und Latenz interaktiver Aufgaben als Abnahmekriterien verwenden
Beobachte bei jeder Sitzung, die transkodiert werden muss, die Verarbeitungsgeschwindigkeit über einen längeren Zeitraum. Ein Stream, der sich um die Echtzeitgeschwindigkeit bewegt, verfügt kaum über Rechenreserve, selbst wenn die Wiedergabe noch nicht gepuffert wurde. Die anhaltende Geschwindigkeit sollte ausreichend über der Echtzeit liegen, um Szenenkomplexität, thermische Veränderungen und konkurrierende Aufgaben aufzufangen.
Miss bei Direct Play oder beim Durchsuchen der Bibliothek die Zeit bis zum ersten Bild, die Reaktion beim Springen, die API-Latenz und die Aufgabendauer, während die Spitzenlast ausgeführt wird. Die ZimaSpace-Analyse zu der ersten Ressource, die ihre Dauerreserve verliert bietet eine nützliche Abbruchregel: Füge erst dann Kapazität hinzu, wenn dieselbe Ressource wiederholt demselben für Nutzer sichtbaren Fehler vorausgeht.
Wenn die CPU-Auslastung hoch bleibt, Transkodierungsgeschwindigkeit, Latenz und Druck jedoch stabil bleiben, nutzt der Rechner seine verfügbare Rechenleistung möglicherweise einfach effizient. Wenn der Druck steigt, sich die Transkodierungsgeschwindigkeit der Echtzeit nähert oder darunter fällt oder die interaktive Latenz sprunghaft zunimmt, ist die praktische CPU-Reserve aufgebraucht.
Den Prozentsatz in eine getestete Betriebsrichtlinie umwandeln
| Arbeitslast | Interpretation der Reserve | Erste Reaktion bei schwindender Reserve |
|---|---|---|
| Überwiegend Direct Play | Der CPU-Prozentsatz ist zweitrangig; halte Burst-Kapazität für Scans und Dienste vor | Zuerst Prozesse außerhalb der Wiedergabe sowie Speicher und Netzwerk prüfen |
| Hardware-Transkodierungen | CPU für Filter, Audio, Orchestrierung und Fallback reservieren | Den vollständigen Beschleunigungspfad überprüfen |
| Software-Transkodierungen | Eine deutliche dauerhafte Reserve oberhalb der erforderlichen Echtzeitaufgabe vorhalten | Konvertierungen reduzieren oder Rechenleistung erhöhen |
| Gemeinsam genutzter Heimserver | Jellyfin zusammen mit normalen Backups, Downloads oder KI-Aufgaben testen | Konkurrierende Arbeitslasten planen, begrenzen oder trennen |
Verwende den Wert von 20–30 % Leerlauf nur als anfängliches Betriebsziel für einen gemischten Server. Bei einem Server mit überwiegend Direct Play kann weniger sicher sein, wenn das Verhalten bei Lastspitzen nachweislich stabil bleibt; bei geschäftskritischer Softwaretranskodierung im Haushalt kann mehr erforderlich sein.
Führe nach Änderungen an Clients, Codecs, Untertitelgewohnheiten, Hardwarebeschleunigung, Plugins oder gemeinsam gehosteten Diensten neue Tests durch. CPU-Reserve ist eine Eigenschaft der aktuellen Arbeitslastkombination und keine dauerhafte Spezifikation der CPU.
Empfohlene Produkte
Support & Tipps
Mehr zum Lesen
Sollte Jellyfin ein gemeinsames Konto oder separate Haushaltskonten verwenden?
Wählen Sie Jellyfin-Haushaltskonten nach den benötigten Grenzen für Identität, Zugriff, Jugendschutz und Wiederherstellung aus.
Warum bleibt der Speicherverbrauch von Jellyfin nach Abschluss der Arbeit hoch?
Unterscheiden Sie das Wachstum des Jellyfin-Prozesses vom Linux-Cache und untersuchen Sie es nur, wenn der Speicherverbrauch weiter ansteigt oder tatsächlich Druck auf den Arbeitsspeicher...
Anzeichen dafür, dass ein Jellyfin-Speicherlayout zum Wiederherstellungsrisiko wird
Prüfen Sie die Speicherrollen von Jellyfin, trennen Sie den laufenden Zustand von Backups und wiederherstellbaren Daten und belegen Sie das Layout durch eine Wiederherstellung.
