Waarom gebruikt Plex na een update zoveel CPU?

Een hoog CPU-gebruik direct na een Plex-update kan tijdelijk migratie- of analysetaken betekenen, maar ga er niet van uit dat dit onbeperkt normaal blijft.

De veiligste diagnose is tijdgebonden. Noteer de updateversie, de starttijd, actieve Plex-processen en schijfactiviteit. Wacht tot expliciete migratie- of analysetaken zijn voltooid en vergelijk daarna het CPU-gebruik tijdens een tweede schone herstart. Als de belasting aanhoudt zonder dat dezelfde taak actief is, verschuif de diagnose van ‘overgang na update’ naar een regressie of analyse van de werklast.

Zoek naar databasemigratie voordat je instellingen wijzigt

Voor sommige Plex-releases moet de bestaande databasestatus worden gescand of aangepast voordat de server volledig gereed is. Dit kan gedurende een beperkte periode CPU en I/O op de appgegevens verbruiken.

Voor sommige releases moeten alle bestaande databaserecords volledig worden gescand voordat het opstarten is voltooid. Beoordeel tijdelijk CPU-gebruik en I/O op de appgegevens daarom pas nadat deze migratie is afgerond, in plaats van dit te vergelijken met normaal inactief gedrag.

Controleer de logboeken op migratieactiviteit en let erop of het CPU-gebruik daalt zodra de server weer gereed is. Onderbreek een bekende migratie niet alleen omdat de eerste herstart langer duurt dan normaal.

Maak onderscheid tussen heranalyse en een vastgelopen proces

Een update kan ook nieuwe of herhaalde media-analyse, voorbeeldweergaven of metagegevensverwerking starten. Deze werklast kan doorgaan nadat de webinterface bereikbaar is en kan lijken op een regressie van de server.

Analyse na een update kan gedurende langere tijd CPU verbruiken. Beschouw koude en opnieuw opgebouwde werksets als een reden waarom het gedrag bij de eerste uitvoering kan verschillen van later inactief gedrag, terwijl je de daadwerkelijke Plex-taak identificeert.

Pauzeer optionele geplande taken of wacht tot de actieve taak is voltooid en herhaal daarna dezelfde observatie tijdens inactiviteit. Als het CPU-gebruik daalt, plan de taak opnieuw in plaats van algemene CPU-limieten te wijzigen.

Vergelijk de tweede herstart

Eenmalige werkzaamheden zouden niet bij elke schone start op dezelfde manier moeten terugkeren. Een tweede herstart na voltooiing is de snelste controletest om migratie te onderscheiden van blijvend gedrag.

Houd het pad naar de appgegevens tijdens de vergelijking ongewijzigd en controleer dezelfde procesnamen en meetwaarden. Het persistente pad naar de appgegevens moet constant blijven, zodat de voltooide update de enige bewust gewijzigde variabele is.

Als de tweede start nog steeds alle CPU-capaciteit gebruikt, verzamel dan de logboeken en bepaal of de werklast afkomstig is van zoeken, scannen, transcoderen of een ander proces. Ga vanaf die concrete werklast verder, niet alleen vanaf de datum van de update.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Rol alleen terug met een veilige statusgrens

Een terugkeer naar een eerdere versie kan riskant zijn als de nieuwere versie opgeslagen gegevens heeft gewijzigd op een manier die de oudere versie niet begrijpt. Bescherm de database van vóór de update voordat je terugrollen als snelle probleemoplossing gebruikt.

Een terugrolactie moet een overeenkomende kopie van de status herstellen, omdat schone herstelpunten bescherming bieden tegen wijzigingen die een oudere binary mogelijk niet veilig kan begrijpen.

Herstel bij een noodzakelijke terugrolactie de bekende, goed werkende status van vóór de update met de bijbehorende versie. Wissel niet af tussen oude en nieuwe binaries op één live database terwijl je probeert het hoge CPU-gebruik te isoleren.