Porque é que o Jellyfin consome muita CPU após uma atualização?

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

Um consumo elevado de CPU pelo Jellyfin após uma atualização costuma ter origem num de quatro pontos: tarefas de arranque ou da base de dados, tarefas agendadas da biblioteca, transcodificação por software ou parcial, ou um plug-in/tarefa em segundo plano cujo comportamento mudou com a nova versão. Não assuma que a atualização tornou permanentemente o Jellyfin mais pesado até identificar qual o processo e a tarefa que estão a consumir a CPU.

O diagnóstico mais rápido consiste em comparar o momento e a carga de trabalho. Se a CPU estiver elevada apenas durante alguns minutos após o arranque, observe os registos de arranque e das tarefas. Se aumentar apenas durante a reprodução, inspecione o fluxo ativo e o caminho do FFmpeg. Se permanecer elevada quando ninguém estiver a ver conteúdo, verifique as tarefas agendadas e os plug-ins. Altere uma variável de cada vez e, em seguida, reproduza a mesma condição para distinguir uma tarefa temporária pós-atualização de uma regressão persistente.

Separe o trabalho de arranque da utilização normal da CPU

Reinicie o Jellyfin uma vez durante um período de pouca atividade e registe durante quanto tempo a CPU permanece elevada. Observe o registo do servidor em busca de mensagens relacionadas com migração, otimização da base de dados, carregamento de plug-ins ou da biblioteca e, em seguida, aguarde até a interface Web e as tarefas agendadas estabilizarem antes de avaliar a nova utilização normal.

As tarefas agendadas e de arranque predefinidas do Jellyfin incluem análises da biblioteca, extração de fotogramas-chave, otimização da base de dados, limpeza da cache e atualizações de plug-ins. Algumas tarefas também são executadas no arranque, pelo que um pico após a atualização pode ser manutenção, e não uma alteração contínua do desempenho.

Se a CPU regressar ao intervalo de inatividade anterior depois de as tarefas terminarem, não ajuste a transcodificação nem substitua o hardware. O seu sistema já convergiu para uma carga temporária em segundo plano; em vez disso, agende as tarefas pesadas fora do horário de visualização se estas interferirem com a reprodução.

Verifique se a reprodução está agora a utilizar a CPU

Se o pico de CPU começar apenas quando um determinado cliente inicia a reprodução, abra o painel do Jellyfin e determine se a sessão está em Reprodução direta, remuxing, transcodificação de áudio ou transcodificação de vídeo. Uma alteração no cliente ou no codec pode ativar um caminho de software que não era utilizado anteriormente.

Force a reprodução do mesmo conteúdo no mesmo cliente com as legendas desativadas e compare a utilização da CPU. Se esta diminuir significativamente, as legendas ou o caminho de transcodificação são o fator diferenciador. Se permanecer elevada durante a Reprodução direta, procure problemas no armazenamento, nos plug-ins ou noutro processo, em vez de culpar o codificador.

Para uma verificação mais aprofundada da reprodução, utilize o mesmo método descrito em verificar se a transcodificação por hardware está a funcionar: confirme o caminho ativo da GPU/FFmpeg em vez de confiar apenas no facto de a aceleração por hardware estar ativada nas definições.

Meça o processo do contentor em vez de fazer suposições com base na carga do anfitrião

Num servidor doméstico partilhado, confirme que o Jellyfin é realmente o processo que está a consumir a CPU. Cópias de segurança, indexadores de multimédia, clientes de transferências, geradores de miniaturas e tarefas de manutenção do sistema de ficheiros podem ter sido iniciados durante o mesmo reinício ou período de atualização.

Os ambientes de execução de contentores disponibilizam vistas de utilização por contentor; o comando stats do Docker foi concebido para mostrar a utilização de recursos em tempo real dos contentores em execução. Utilize a utilização de recursos por contentor ou o equivalente da sua plataforma enquanto reproduz o problema.

Se outro contentor estiver a utilizar a CPU, pause essa tarefa e repita o teste original. Se for o Jellyfin, continue a investigar as tarefas e a reprodução do Jellyfin; caso contrário, a atualização apenas coincidiu com a carga do anfitrião, não sendo a causa.

Desative ou reagende uma fonte em segundo plano de cada vez

Verifique a página de tarefas agendadas do Jellyfin para identificar uma tarefa atualmente em execução ou que esteja a reiniciar repetidamente. Reveja também os plug-ins que adicionam tarefas agendadas próprias, fornecedores de metadados, deteção de introduções, processamento de legendas ou outra automatização da biblioteca.

Não desative permanentemente todos os plug-ins e tarefas num único passo. Pause um candidato de elevado consumo, deixe a CPU estabilizar e, em seguida, reproduza a mesma condição de inatividade ou análise. Uma diminuição clara identifica o ramo responsável; se não houver alteração, reative-o e teste o candidato seguinte.

Se a tarefa for legítima, mas estiver mal agendada, reagende-a em vez de a tratar como um defeito. Se entrar em ciclo, falhar ou reiniciar imediatamente após a atualização, guarde os registos e as informações da versão do plug-in antes de alterar ficheiros da base de dados ou reconstruir o servidor.

Confirme a correção com a carga original após a atualização

Depois de identificar a causa, aplique a correção adequada: deixe as migrações terminar, reagende uma tarefa, restaure a aceleração por hardware, atualize ou desative um plug-in problemático, ou corrija a condição do cliente/transcodificação. Em seguida, reinicie uma vez e repita exatamente o teste que anteriormente elevou a utilização da CPU.

Uma correção bem-sucedida significa que o comportamento da CPU volta a corresponder à carga de trabalho: a inatividade estabiliza após o arranque, uma Reprodução direta mantém uma utilização reduzida e qualquer transcodificação necessária utiliza o caminho de aceleração esperado. Um período tranquilo de um minuto, sem repetir o fator desencadeante, não é suficiente.

Procure assistência quando a CPU permanecer elevada sem tarefas em execução, sem transcodificação, sem outro contentor concorrente e com uma configuração limpa de plug-ins. Nesse caso, recolha a versão do Jellyfin, o sistema operativo/a arquitetura, o estado das tarefas e um breve intervalo de registos, para que uma regressão específica da versão possa ser investigada sem tirar conclusões gerais a partir de um arranque ocupado.

Suporte e Dicas

Mais para Ler

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.