Hoeveel CPU-capaciteit moet je reserveren voor pieken in Jellyfin?
Er is geen universeel percentage CPU-reservecapaciteit voor Jellyfin, omdat Direct Play, hardwaretranscodering, het inbranden van ondertitels, softwarematige fallback, bibliotheekbewerkingen en naburige containers de CPU op zeer verschillende manieren gebruiken.
Voor een gemengde homeserver is het een redelijk uitgangspunt om tijdens de zwaarste normale aanhoudende belasting ongeveer 20–30% van de totale CPU-capaciteit ongebruikt te houden. Dit is geen vereiste van Jellyfin. De echte acceptatiecriteria zijn dat korte pieken geen wachtrijen veroorzaken, de transcodeersnelheid waar nodig veilig boven realtime blijft, hotspots per core beheersbaar blijven en de voorgrondlatentie stabiel blijft wanneer normale achtergrondtaken samenvallen.
Meet de zwaarste normale combinatie, niet een dashboard in rust
Stel de piekbelasting samen die het huishouden daadwerkelijk verwacht: de minst compatibele client, het vereiste ondertitel- of HDR-pad, het verwachte aantal gelijktijdige sessies en één normale achtergrondtaak of naburige container die kan overlappen. Een kunstmatige stresstest is alleen nuttig als die belasting in werkelijkheid kan voorkomen.
CPU-gebruik alleen laat niet zien of werk staat te wachten. De methode voor gebruik, verzadiging en fouten controleert zowel hoe druk een resource is als of aanvragen erachter in een wachtrij belanden. Combineer voor Jellyfin het CPU-percentage met load of druk, uitvoerbare taken, gebruik per core, afspeellatentie en transcodeersnelheid.
Leg eerst een stabiele referentiemeting vast en voeg daarna sessie voor sessie of achtergrondtaak voor achtergrondtaak toe. De vereiste reservecapaciteit begint op het moment dat een extra belasting een meetbare wachtrij of gemiste realtime deadline veroorzaakt, niet wanneer de CPU-grafiek er simpelweg hoog uitziet.
Reserveer meer CPU voor softwarematige en gedeeltelijk versnelde paden
Een Direct Play-server kan zelfs met meerdere kijkers zeer weinig CPU gebruiken. Een softwarematige videotranscode kan de meeste beschikbare cores belasten, terwijl hardwareversnelling nog steeds audioconversie, ondertiteling, filters, orkestratie of fallback-werk op de CPU kan overlaten.
De uitsplitsing van ZimaSpace van de CPU-behoefte per daadwerkelijke Jellyfin-belasting vormt de relevante grens voor dimensionering: het aantal cores is pas van belang nadat je weet welke stappen op algemene rekenkracht blijven draaien.
Als een vereiste softwarematige transcode de CPU al bijna volledig belast, biedt een nominale gemiddelde reserve van 10% geen betekenisvolle bescherming tegen een tweede stream, het inbranden van ondertitels of achtergrondanalyse. Houd dan een grotere marge aan, verbeter het versnellingspad, converteer moeilijke media vooraf of voorkom dat zware achtergrondtaken tijdens het kijken worden uitgevoerd.
Controleer verzadiging per core voordat je het gemiddelde vertrouwt
Een CPU met acht cores kan een matig totaalgebruik tonen terwijl één of twee threads volledig zijn belast. Dat is belangrijk wanneer een filter, audiopad, databasetaak of single-threadgevoelige bewerking de voor de gebruiker zichtbare latentie bepaalt.
Bekijk naast het totaalcijfer ook het gebruik per core en de CPU-druk. De CPU-drukmetingen van Linux geven aan hoeveel tijd taken geblokkeerd wachten op CPU-capaciteit. Voor piekdiagnose is dat nuttiger dan alleen het gebruik. Een hoog gemiddelde met weinig wachtrijen kan voor batchverwerking acceptabel zijn, terwijl een lager gemiddelde met één verzadigde kritieke thread haperingen of trage navigatie kan veroorzaken.
Los een enkele hete thread niet op door zonder controle veel meer trage cores aan te schaffen. Controleer eerst of de belasting die cores kan gebruiken. Als de bottleneck een specifieke softwarefilter of fallback-route is, kan het aanpassen van het afspeelpad meer effectieve reservecapaciteit opleveren dan een hogere totale benchmarkscore.
Gebruik transcodeersnelheid en voorgrondlatentie als acceptatiemaatstaven
Houd voor elke sessie die moet transcoderen de verwerkingssnelheid gedurende een stabiele meetperiode in de gaten. Een stream die rond realtime blijft hangen, heeft vrijwel geen rekenmarge, zelfs als het afspelen nog niet is gaan bufferen. Je wilt een voldoende stabiele snelheid boven realtime om complexere scènes, temperatuurschommelingen en concurrerende taken op te vangen.
Meet bij Direct Play of het bladeren door de bibliotheek de tijd tot het eerste beeld, de reactiesnelheid bij zoeken, de API-latentie en de taakduur terwijl de piekcombinatie actief is. De analyse van ZimaSpace over de eerste resource die zijn aanhoudende marge verliest biedt een nuttige stopregel: voeg pas capaciteit toe wanneer dezelfde resource herhaaldelijk voorafgaat aan dezelfde zichtbare gebruikersfout.
Als de CPU hoog blijft, maar de transcodeersnelheid, latentie en druk stabiel blijven, gebruikt de machine de beschikbare rekenkracht mogelijk gewoon efficiënt. Als de druk toeneemt, de transcodeersnelheid realtime nadert of daaronder zakt, of de interactieve latentie sterk stijgt, is de praktische reservecapaciteit opgebruikt.
Maak van het percentage een getest gebruiksbeleid
| Belasting | Interpretatie van de reservecapaciteit | Eerste reactie wanneer de marge verdwijnt |
|---|---|---|
| Voornamelijk Direct Play | Het CPU-percentage is van ondergeschikt belang; behoud burstcapaciteit voor scans en services | Controleer eerst processen buiten het afspelen en de opslag of het netwerk |
| Hardwaretranscodering | Reserveer CPU voor filters, audio, orkestratie en fallback | Controleer het volledige versnellingspad |
| Softwarematige transcodering | Houd een ruime stabiele marge boven de vereiste realtime taak | Verminder het aantal conversies of verhoog de rekenkracht |
| Gedeelde homeserver | Test Jellyfin samen met normale back-ups, downloads of AI-belasting | Plan, beperk of scheid concurrerende belastingen |
Gebruik het getal van 20–30% ongebruikte capaciteit alleen als aanvankelijk gebruiksdoel voor een gemengde server. Minder kan veilig zijn voor een server met voornamelijk Direct Play en aantoonbaar goed piekgedrag; meer kan nodig zijn wanneer softwarematige transcodering essentieel is voor het huishouden.
Test opnieuw na wijzigingen in clients, codecs, ondertitelgewoonten, hardwareversnelling, plug-ins of naast elkaar gehoste services. Reservecapaciteit is een eigenschap van de huidige combinatie van belastingen, geen permanente specificatie van de CPU.
Aanbevolen producten
Ondersteuning & Tips
Meer om te lezen
Moet Jellyfin één gedeeld account of afzonderlijke huishoudaccounts gebruiken?
Kies Jellyfin-huishoudaccounts op basis van de identiteits-, toegangs-, ouderlijketoezichts- en herstelgrenzen die je nodig hebt.
Waarom blijft het geheugengebruik van Jellyfin hoog nadat het werk is voltooid?
Maak onderscheid tussen geheugengroei van het Jellyfin-proces en de Linux-cache, en onderzoek het alleen wanneer het geheugengebruik blijft stijgen of daadwerkelijk voor druk zorgt.
Signalen dat een Jellyfin-opslagindeling een herstelrisico begint te vormen
Controleer de opslagrollen van Jellyfin, scheid de actieve toestand van back-ups en opnieuw opbouwbare gegevens, en toon met een herstel aan dat de indeling...
