Hoe kun je bepalen of Jellyfin wordt beperkt door de CPU, het geheugen, het netwerk of de opslag?

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

How Can You Tell Whether Jellyfin Is CPU-, Memory-, Network-, or Storage-Bound? - Zima Store Online

Je kunt het knelpunt van Jellyfin identificeren door één werklast te herhalen en het symptoom dat de gebruiker ziet te koppelen aan de resource die verzadigd raakt door fouten of wachtrijen.

Een hoge CPU-grafiek bewijst niet dat de CPU de beperking vormt, net zoals actieve opslag niet bewijst dat opslag de oorzaak is. Gebruik steeds hetzelfde bestand, dezelfde client, dezelfde kwaliteitsinstelling en hetzelfde aantal sessies, en wijzig telkens slechts één voorwaarde. Zo maak je onderscheid tussen een echte afhankelijkheidslimiet en een zwaarder afspeelpad dat door de client is geselecteerd.

Houd de afspeelcase constant

Kies één mediabestand, één client, één kwaliteitsbeleid en één gelijktijdigheidsniveau. Noteer of de sessie Direct Play gebruikt, remuxt of transcodeert voordat je resourcegrafieken bekijkt, want de afspeelmodus bepaalt welke resources actief zouden moeten zijn.

Begin met Direct Play naar transcoding, zodat het serverpad bekend is voordat je het gedrag van resources vergelijkt.

Een gecontroleerde nulmeting voorkomt dat je een browsertranscode vergelijkt met een native Direct Play-sessie en het verschil vervolgens een hardwareknelpunt noemt.

CPU en geheugen laten verschillende patronen zien

CPU-gebonden werk houdt meestal verband met softwaredecodering, filters, ondertiteling of codering, terwijl geheugendruk zichtbaar wordt als reclaim, swapping, vastgelopen workers of toenemende opslagactiviteit door paging. De symptomen kunnen elkaar overlappen, maar hun tellers verschillen.

Gebruik gebruik en verzadiging om gebruik, verzadiging en fouten samen te inspecteren, in plaats van een gemiddeld CPU- of RAM-gebruik als oordeel te gebruiken.

Als het pauzeren van een filter of overschakelen naar hardwaredecodering de realtime snelheid herstelt zonder opslag of netwerk te wijzigen, wijst dat op CPU-belasting. Als reclaim of swap verdwijnt wanneer een andere container stopt, is geheugendruk de waarschijnlijkere verklaring.

Netwerk en opslag vereisen padgerichte tests

Een verzadigde uploadsnelheid kan externe weergave laten bufferen terwijl de CPU van de host nauwelijks wordt belast. Opslaglatentie kan het starten, zoeken, metadata en tijdelijke transcodebestanden vertragen, zelfs wanneer de sequentiële doorvoer voldoende lijkt. Test het pad dat de client daadwerkelijk gebruikt.

Meet opslaglatentie en doorvoer afzonderlijk van de doorvoer, en vergelijk dezelfde stream terwijl concurrerende overdrachten zijn gepauzeerd.

Als het symptoom de wachtrijdiepte of het uploadgebruik volgt, lossen wijzigingen aan CPU of RAM het niet op. Als het symptoom blijft bestaan nadat het pad niet langer wordt belast, richt je dan op compatibiliteit van de client of op rekenkracht.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

Gebruik een matrix met vier resources

Noteer voor elke test het waarneembare symptoom, de eerste teller die verzadigd raakt, of het aantal fouten stijgt en of het wegnemen van de druk op die resource de nulmeting herstelt. Eén positief signaal is niet voldoende; de relatie moet zich bij herhaalde tests blijven voordoen.

Een beknopte koude en warme benchmark houdt de beslissing gericht op bewijs in plaats van op de reflex om te upgraden.

Stop zodra één resource het symptoom tijdens herhaalde tests verklaart. Als geen enkele resource het symptoom volgt, kan het actieve probleem liggen bij de gebruikersinterface van de client, de opstartvolgorde of een wijziging van afspeelmodus buiten de test met vier resources.