Porque é que o Plex utiliza muita CPU depois de uma atualização?

Um uso elevado do CPU imediatamente após uma atualização do Plex pode dever-se temporariamente a tarefas de migração ou análise, mas não deve ser considerado normal indefinidamente.

O diagnóstico mais seguro é limitado no tempo. Registe a versão da atualização, a hora de arranque, os processos ativos do Plex e a atividade do disco. Aguarde que as tarefas explícitas de migração ou análise terminem e, em seguida, compare o uso do CPU durante um segundo reinício limpo. Se a carga persistir sem a mesma tarefa, passe de uma “transição da atualização” para um diagnóstico de regressão ou da carga de trabalho.

Procure uma migração da base de dados antes de alterar definições

Algumas versões do Plex exigem que o estado existente da base de dados seja analisado ou transformado antes de o servidor ficar totalmente pronto. Esse trabalho pode consumir CPU e I/O dos dados da aplicação durante um período limitado.

Algumas versões exigem uma análise completa dos registos existentes da base de dados antes de o arranque terminar, pelo que o uso temporário do CPU e o I/O dos dados da aplicação devem ser avaliados em função do fim dessa migração, e não do comportamento normal em inatividade.

Verifique os registos em busca de atividade de migração e observe se o uso do CPU diminui quando o estado de pronto é restabelecido. Não interrompa uma migração conhecida apenas porque o primeiro reinício é mais lento do que o habitual.

Distingua a reanálise de um processo bloqueado

Uma atualização também pode desencadear trabalhos novos ou repetidos de análise de multimédia, pré-visualização ou metadados. Essa carga de trabalho pode continuar depois de a interface Web estar acessível e parecer uma regressão do servidor.

A análise após uma atualização pode consumir CPU durante um período prolongado; considere conjuntos de trabalho frios e em reconstrução como uma das razões pelas quais o comportamento na primeira execução pode diferir do comportamento posterior em inatividade, enquanto identifica a tarefa efetiva do Plex.

Pare as tarefas agendadas opcionais ou aguarde que o trabalho ativo termine e, em seguida, repita a mesma observação em inatividade. Se o uso do CPU diminuir, reagende a tarefa em vez de alterar os limites globais do CPU.

Compare o segundo reinício

Um trabalho pontual não deve repetir-se de forma idêntica em todos os arranques limpos. Um segundo reinício após a conclusão é o teste de controlo mais rápido para distinguir uma migração de um comportamento persistente.

Mantenha o caminho dos dados da aplicação inalterado durante a comparação e monitorize os mesmos nomes de processos e métricas. O caminho persistente dos dados da aplicação deve permanecer constante, para que a única variável deliberada seja a atualização concluída.

Se o segundo arranque continuar a consumir todo o CPU, recolha os registos e identifique se a carga de trabalho é uma pesquisa, análise, transcodificação ou outro processo. Prossiga a partir dessa carga de trabalho concreta, e não apenas da data da atualização.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Reverta apenas com um limite de estado seguro

Uma reversão binária pode ser arriscada se a versão mais recente tiver alterado o estado armazenado de uma forma que a versão anterior não compreenda. Proteja a base de dados anterior à atualização antes de utilizar a reversão como atalho de resolução de problemas.

Uma reversão deve restaurar uma cópia de estado correspondente, porque os pontos de recuperação limpos protegem contra alterações que um binário mais antigo pode não compreender com segurança.

Quando for necessária uma reversão, restaure o estado anterior à atualização que se sabe estar em boas condições, utilizando a versão correspondente. Não alterne entre binários antigos e novos na mesma base de dados ativa enquanto tenta isolar o uso elevado do CPU.