Perché Plex utilizza molta CPU dopo un aggiornamento?
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.
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.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Jellyfin può condividere in sicurezza una GPU o un acceleratore con un altro container?
La condivisione della GPU è condizionata: verifica la visibilità del dispositivo e il supporto dei driver, quindi esegui entrambi i carichi di lavoro e...
Come capire se un errore di Jellyfin proviene dal client o dal server
Un errore di Jellyfin è imputabile al client quando si verifica su un solo dispositivo; è imputabile al server quando più client falliscono seguendo...
Come configurare la cache e l’archiviazione temporanea di Jellyfin
Separa lo stato persistente, la cache ricostruibile e lo spazio temporaneo per la transcodifica, quindi verifica la capacità e i permessi con un test...
