Perché Plex utilizza molta CPU dopo un aggiornamento?

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Why Does Plex Use High CPU After an Update? - Zima Store Online

Un utilizzo elevato della CPU subito dopo un aggiornamento di Plex può dipendere temporaneamente da attività di migrazione o analisi, ma non va considerato normale a tempo indeterminato.

La diagnosi più sicura deve essere circoscritta nel tempo. Annota la versione dell’aggiornamento, l’ora di avvio, i processi Plex attivi e l’attività del disco. Attendi il completamento esplicito delle attività di migrazione o analisi, quindi confronta l’utilizzo della CPU durante un secondo riavvio pulito. Se il carico persiste senza la stessa attività, passa dalla diagnosi di “transizione dell’aggiornamento” a quella di una regressione o del carico di lavoro.

Cerca una migrazione del database prima di modificare le impostazioni

Alcune versioni di Plex richiedono che lo stato esistente del database venga analizzato o trasformato prima che il server sia completamente pronto. Questa attività può consumare CPU e I/O dei dati dell’applicazione per un periodo limitato.

Alcune versioni richiedono una scansione completa dei record del database esistenti prima del completamento dell’avvio; pertanto, l’utilizzo temporaneo della CPU e l’I/O dei dati dell’applicazione vanno valutati in relazione alla fine della migrazione, non rispetto al normale comportamento in inattività.

Controlla i log per verificare la presenza di attività di migrazione e osserva se l’utilizzo della CPU diminuisce quando il server torna pronto. Non interrompere una migrazione nota solo perché il primo riavvio è più lento del solito.

Distingui la rianalisi da un processo bloccato

Un aggiornamento può anche avviare nuove analisi dei contenuti multimediali, delle anteprime o dei metadati, oppure ripeterle. Questo carico di lavoro può continuare anche dopo che l’interfaccia web è tornata accessibile e può sembrare una regressione del server.

L’analisi successiva all’aggiornamento può consumare CPU per un periodo prolungato; considera i working set freddi e in ricostruzione come una delle ragioni per cui il comportamento al primo avvio può differire da quello nei successivi periodi di inattività, mentre individui l’attività Plex effettiva.

Sospendi le attività pianificate facoltative oppure attendi il completamento del processo attivo, quindi ripeti la stessa osservazione in condizioni di inattività. Se l’utilizzo della CPU diminuisce, riprogramma l’attività invece di modificare i limiti globali della CPU.

Confronta il secondo riavvio

Le attività eseguite una sola volta non dovrebbero ripetersi nello stesso modo a ogni avvio pulito. Un secondo riavvio dopo il completamento è il test di controllo più rapido per distinguere una migrazione da un comportamento persistente.

Mantieni invariato il percorso dei dati dell’applicazione durante il confronto e monitora gli stessi nomi dei processi e le stesse metriche. Il percorso persistente dei dati dell’applicazione deve rimanere costante, così l’unica variabile modificata deliberatamente sarà l’aggiornamento completato.

Se anche il secondo avvio porta la CPU al massimo, raccogli i log e identifica se il carico di lavoro riguarda la ricerca, la scansione, la transcodifica o un altro processo. Prosegui partendo da quel carico concreto, non solo dalla data dell’aggiornamento.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

Esegui il rollback solo con un confine di stato sicuro

Un rollback binario può essere rischioso se la versione più recente ha modificato lo stato memorizzato in un modo che la versione precedente non è in grado di interpretare. Proteggi il database precedente all’aggiornamento prima di usare il rollback come scorciatoia per la risoluzione dei problemi.

Un rollback dovrebbe ripristinare una copia dello stato corrispondente, perché i punti di ripristino puliti proteggono dalle modifiche che una versione binaria precedente potrebbe non essere in grado di gestire in sicurezza.

Quando è necessario un rollback, ripristina lo stato noto come funzionante prima dell’aggiornamento insieme alla versione corrispondente. Non alternare versioni binarie vecchie e nuove sullo stesso database attivo mentre cerchi di isolare l’utilizzo elevato della CPU.