Så ser du om Plex begränsas av CPU, RAM-minne, lagring eller nätverk
Du kan se vad som begränsar Plex genom att återskapa en känd arbetsbelastning och leta efter den resurs vars belastning ökar samtidigt som uppspelningen blir långsammare. Uppgradera inte den komponent som ser mest belastad ut först; hög användning är bara relevant när den sammanfaller med uppspelningsfelet.
Börja med en fil, en klient, ett uppspelningsläge och ett tidsfönster. Separera sedan Plex konverteringsarbete från operativsystemets signaler för processor, minne, lagring och nätverk. Testet är klart först när en ändring av en misstänkt resurs förändrar det ursprungliga Plex-symptomet medan övriga förhållanden förblir stabila.
Återskapa en Plex-arbetsbelastning innan du läser systemmätvärden
Välj en fil och klient som pålitligt återskapar problemet. Notera om symptomet är långsam start, upprepad buffring, en omkodning som inte hinner med, en skanning som gör uppspelningen långsam eller ett fel som bara uppstår på distans, eftersom varje symtom pekar på en annan väntetyp.
Ett Plex-specifikt felsökningsflöde bör börja med den aktiva sessionen i stället för ett generiskt processor diagram. En praktisk kontroll med instrumentpanelen först skiljer mellan Direct Play, omkodning, nätverk och lagring innan du börjar ändra servern.
Håll filen, valda ljud- och textspår, klientens kvalitet och samtidiga arbetsbelastning oförändrade medan du samlar in systemmätvärden. Om symptomet varierar mellan testerna ska du förenkla arbetsbelastningen tills samma fel upprepas; annars kan en senare processor- eller diskspik tillhöra ett annat jobb.
Använd Plex-sessionen för att skilja leverans från konvertering
Läs Plex-sessionen medan problemet pågår. Direct Play innebär att servern huvudsakligen levererar det lagrade mediet, medan en videoomkodning lägger till en konverteringssökväg i realtid som kan flytta flaskhalsen mot processorn eller maskinvaruaccelererade videoenheter.
Använd läget som en förgrening, inte som en slutsats. En omkodning som inte hinner med gör beräkningskapacitet till en stark kandidat, men buffring vid Direct Play innebär att lagring och nätverk fortfarande är möjliga orsaker. Om samma fil byter läge när undertexter, ljud eller kvalitet ändras ska du återskapa problemet igen med den ursprungliga begäran innan du jämför värddatorns mätvärden.
Utgången från det här avsnittet är ett fast uppspelningsläge kopplat till symptomet. Om du inte kan säga om det felande testet är Direct Play eller omkodning ska du stanna här; att jämföra RAM-, disk- och nätverksdata innan mediesökvägen är stabil gör de återstående mätvärdena svårare att tolka.
Testa processor- och RAM-belastning tillsammans
Övervaka processoranvändning, körkö eller belastning, tillgängligt minne och swap-aktivitet under det fasta Plex-testet. Processorbelastning är mest betydelsefull när Plex-processen eller dess omkodare använder ihållande beräkningskapacitet samtidigt som utdata hamnar efter; minnesbelastning är mer sannolik när systemet börjar återvinna minne eller använda swap och svarstiden försämras, även om processorn inte är den enda upptagna resursen.
Ett allmänt Linux-arbetsflöde för prestanda använder verktyg som top, vmstat, iostat och sar för att skilja olika typer av resursbelastning åt. Framför allt behöver processor, minne, disk och nätverk olika mättnadssignaler i stället för ett enda övergripande användningstal.
Om processorn ligger nära sin gräns endast under den felande omkodningen och strömmen återhämtar sig när konverteringen tas bort eller accelereras, ska du behandla beräkningskapacitet som den ledande flaskhalsen. Om swap-användning eller minnesåtervinning i stället ökar ska du minska antalet samtidiga minneskrävande jobb eller lägga till minne och sedan upprepa samma Plex-arbetsbelastning innan du ändrar inställningar för lagring eller nätverk.
Testa lagringen med samma mediesökväg
För lagring ska du läsa samma media från samma filsystem medan symptomet återskapas och övervaka enhetsfördröjning, köbildning och I/O-väntetid. Kapacitet och prestanda är separata saker: en disk kan ha ledigt utrymme och ändå svara långsamt eftersom ett annat jobb skapar slumpmässig I/O eller eftersom mediesökvägen går via en upptagen lagringspool eller nätverksmontering.
Linux-verktyg som iostat och iotop är användbara eftersom diskens I/O-väntetid och enhetens genomströmning visar ett annat felläge än hög processoranvändning eller swap-aktivitet. Jämför dessa siffror med det exakta buffringsintervallet i stället för med ett genomsnitt när systemet är inaktivt.
Om filen läses utan problem medan Plex buffrar blir lagring mindre sannolik som orsak. Om fördröjning och köbildning ökar samtidigt som symptomet uppstår ska du pausa det konkurrerande diskjobbet eller flytta testfilen till en känd snabb lokal sökväg; om Plex omedelbart återhämtar sig under samma uppspelningsläge har lagring gått från misstanke till bevis.
Testa nätverkets genomströmning längs den faktiska sökvägen
Testa sökvägen mellan servern och klienten separat från Plex. En lokal trådbunden klient kan skilja ett problem med fjärranslutningen från ett resursproblem som gäller hela servern, medan ett genomströmningstest från ände till ände kan visa om sökvägen klarar mediebitraten utan att vara beroende av Plex-programmet.
Använd ett verktyg som iperf3 när du kontrollerar båda ändarna. Ett nätverkstest bör mäta genomströmning, paketförlust och fördröjning, eftersom en angiven länkhastighet inte bevisar att den faktiska sökvägen levererar stabil applikationstrafik.
Om det oberoende nätverkstestet försämras kraftigt medan processor, minne och lagring förblir välmående ska du åtgärda sökvägen innan du finjusterar omkodaren. Om nätverket har gott om uthållig kapacitet och Plex-symptomet kvarstår i ett lokalt trådbundet test ska du återgå till serverns resursförgrening i stället för att köpa en snabbare router.
Ändra endast den resurs som misslyckades i testet
Välj den första resurs som misslyckades i ett särskiljande test och gör en ändring som endast bör påverka den förgreningen. Exempel är att aktivera en verifierad maskinvaruomkodning för en beräkningsbegränsad ström, minska ett minneskrävande bakgrundsjobb, schemalägga om en diskintensiv uppgift eller kringgå en svag nätverkspunkt.
För Plex-specifik uppföljning erbjuder ZimaSpace felsökningsvägen för buffring en djupare fortsättning när du vet om uppspelningsläge, konverteringsbelastning, nätverksstabilitet eller lagringens svarstid är den förgrening du behöver ändra.
Upprepa den ursprungliga filen, klienten och uppspelningsläget efter ändringen. Kalla en komponent för flaskhals först när det ursprungliga symptomet förbättras och den matchande belastningssignalen minskar eller får större marginal. Om symptomet är oförändrat ska du återställa utgångsläget och testa nästa förgrening i stället för att stapla uppgraderingar tills den verkliga orsaken försvinner av en slump.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
