Hoe je kunt bepalen of Plex wordt beperkt door de CPU, het RAM-geheugen, de opslag of het netwerk

Je kunt vaststellen wat Plex beperkt door één bekende werklast te reproduceren en te zoeken naar de resource waarvan de belasting tegelijk stijgt met het vertragen van de stream. Upgrade niet als eerste het component dat er het drukst uitziet; hoge benutting is alleen relevant wanneer die samenvalt met de afspeelfout.

Begin met één bestand, één client, één afspeelmodus en één tijdsvenster. Scheid vervolgens het conversiewerk van Plex van de signalen van het besturingssysteem voor CPU, geheugen, opslag en netwerk. De test is pas voltooid wanneer het wijzigen van één vermoedelijke resource het oorspronkelijke Plex-symptoom verandert terwijl de overige omstandigheden stabiel blijven.

Reproduceer één Plex-werklast voordat je systeemmetingen leest

Kies een bestand en client waarmee je het probleem betrouwbaar kunt reproduceren. Noteer of het symptoom bestaat uit langzaam starten, herhaald bufferen, een transcode die achterloopt, een scan die het afspelen vertraagt of een fout die alleen op afstand optreedt, omdat elk symptoom naar een ander wachtpad wijst.

Een Plex-specifieke probleemoplossingsprocedure moet beginnen bij de actieve sessie en niet bij een algemene CPU-grafiek. Een praktische controle vanuit het dashboard scheidt Direct Play, transcodering, netwerk en opslag voordat je de server gaat aanpassen.

Houd het bestand, de geselecteerde tracks, de clientkwaliteit en de gelijktijdige werklast ongewijzigd terwijl je systeemmetingen verzamelt. Als het symptoom tussen tests verschuift, vereenvoudig de werklast dan totdat dezelfde fout zich herhaaldelijk voordoet; anders kan een latere CPU- of piekbelasting van de schijf bij een andere taak horen.

Gebruik de Plex-sessie om levering en conversie te onderscheiden

Lees de Plex-sessie terwijl het probleem optreedt. Direct Play betekent dat de server de opgeslagen media grotendeels aflevert, terwijl een videotranscode een echte realtime-conversiestap toevoegt die de bottleneck kan verschuiven naar de CPU of hardwarematige video-engines.

Gebruik die modus als een vertakking, niet als conclusie. Een transcode die achterloopt maakt rekenkracht een sterke kandidaat, maar buffering bij Direct Play houdt opslag en netwerk nog steeds in beeld. Als hetzelfde bestand van modus wisselt wanneer ondertiteling, audio of kwaliteit verandert, reproduceer het probleem dan opnieuw met het oorspronkelijke verzoek voordat je hostmetingen vergelijkt.

Je verlaat deze sectie pas wanneer een vaste afspeelmodus aan het symptoom is gekoppeld. Als je niet kunt aangeven of de falende test Direct Play of Transcode gebruikt, stop dan hier; RAM-, schijf- en netwerkgegevens vergelijken voordat het mediapad stabiel is, maakt de resterende metingen moeilijker te interpreteren.

Test CPU- en RAM-belasting samen

Bekijk het CPU-gebruik, de run-queue of load, het beschikbare geheugen en de swapactiviteit tijdens de vaste Plex-test. CPU-belasting is het duidelijkst wanneer het Plex-proces of de transcoder langdurig rekenkracht verbruikt terwijl de uitvoer achterloopt; geheugenbelasting is waarschijnlijker wanneer het systeem geheugen begint terug te winnen of te swappen en de responstijd verslechtert, ook al is de CPU niet de enige druk belaste resource.

Een algemene Linux-workflow voor prestatieanalyse gebruikt tools zoals top, vmstat, iostat en sar om resourcebelasting te onderscheiden. Met name CPU, geheugen, schijf en netwerk vereisen verschillende signalen voor verzadiging in plaats van één algemeen benuttingspercentage.

Als de CPU alleen tijdens de falende transcode bijna zijn limiet bereikt en de stream herstelt wanneer conversie wordt verwijderd of versneld, beschouw rekenkracht dan als de belangrijkste bottleneck. Als swapping of het terugwinnen van geheugen juist toeneemt, verminder dan gelijktijdige geheugenintensieve taken of voeg geheugen toe en herhaal daarna dezelfde Plex-werklast voordat je opslag- of netwerkinstellingen aanpast.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Test opslag met hetzelfde mediapad

Lees voor opslag dezelfde media vanaf hetzelfde bestandssysteem terwijl het symptoom zich opnieuw voordoet en let op apparaatlatentie, wachtrijen en I/O-wait. Capaciteit en prestaties zijn verschillend: een schijf kan vrije ruimte hebben en toch traag reageren doordat een andere taak willekeurige I/O veroorzaakt of doordat het mediapad achter een drukke pool of netwerkmount zit.

Linux-tools zoals iostat en iotop zijn nuttig omdat I/O-wait van de schijf en de doorvoer van het apparaat een andere foutmodus blootleggen dan hoge CPU- of swapactiviteit. Vergelijk die cijfers met het exacte bufferingsinterval en niet met een gemiddelde tijdens inactiviteit.

Als het bestand probleemloos wordt gelezen terwijl Plex buffert, wordt opslag minder waarschijnlijk. Als latentie en wachtrijen samen met het symptoom stijgen, pauzeer dan de concurrerende schijftaak of verplaats het testbestand naar een bekend snel lokaal pad; als Plex in dezelfde afspeelmodus onmiddellijk herstelt, is opslag niet langer alleen verdacht maar vormt het bewijs.

Test de netwerkdoorvoer over het daadwerkelijke pad

Test het pad tussen server en client afzonderlijk van Plex. Een lokale client met een bekabelde verbinding kan een probleem met de externe route onderscheiden van een serverbreed resourceprobleem, terwijl een end-to-end-doorvoertest kan laten zien of het pad de mediasnelheid aankan zonder afhankelijk te zijn van de Plex-applicatie.

Gebruik een tool zoals iperf3 wanneer je beide uiteinden beheert. Een netwerktest moet kijken naar doorvoer, pakketverlies en latentie, omdat een opgegeven verbindingssnelheid niet bewijst dat de daadwerkelijke route stabiel applicatieverkeer aflevert.

Als de onafhankelijke netwerktest instort terwijl CPU, geheugen en opslag gezond blijven, los dan eerst het netwerkpad op voordat je de transcoder afstemt. Als het netwerk voldoende aanhoudende reservecapaciteit heeft en het Plex-symptoom tijdens een lokale bekabelde test blijft bestaan, ga dan terug naar de serverresourcevertakking in plaats van een snellere router te kopen.

Wijzig alleen de resource die de test niet doorstond

Kies de eerste resource die een onderscheidende test niet doorstond en voer één wijziging door die alleen die vertakking zou moeten beïnvloeden. Voorbeelden zijn het inschakelen van geverifieerde hardwarematige transcoding voor een rekeningsgebonden stream, het verminderen van een geheugenintensieve achtergrondtaak, het opnieuw plannen van een schijfintensieve taak of het omzeilen van een zwakke netwerkkoppeling.

Voor Plex-specifieke vervolgstappen biedt het diagnostische bufferingpad van ZimaSpace een uitgebreid vervolg zodra je weet of de afspeelmodus, conversiebelasting, netwerkstabiliteit of opslagresponsiviteit de vertakking is die je moet wijzigen.

Herhaal na de wijziging hetzelfde bestand, dezelfde client en dezelfde afspeelmodus. Noem een component pas de bottleneck wanneer het oorspronkelijke symptoom verbetert en het bijbehorende belastingssignaal daalt of meer reservecapaciteit krijgt. Als het symptoom onveranderd blijft, herstel dan de uitgangssituatie en test de volgende vertakking in plaats van upgrades op elkaar te stapelen totdat de echte oorzaak toevallig verdwijnt.