Reserve margem de CPU suficiente no Plex para absorver a sobreposição entre a transcodificação normal mais exigente e as tarefas em segundo plano, sem saturação contínua nem instabilidade na reprodução.
Não existe uma percentagem universal, porque a Reprodução direta, a transcodificação por software, a aceleração por hardware, as legendas, as análises e os contentores auxiliares utilizam a CPU de formas diferentes. Crie um cenário de pico repetível e meça a saturação, não apenas a utilização média. A margem é a diferença entre o pico testado e o ponto em que começam a surgir latência ou erros.
Comece pela carga de trabalho normal mais exigente
Um teste sintético de todos os núcleos não representa o Plex se a maioria das sessões utilizar a Reprodução direta. Recrie a combinação de streams, legendas, análises e serviços auxiliares que realmente se sobrepõem em casa.
Utilize verificações de utilização e saturação para determinar se a CPU está simplesmente ocupada ou se existe uma fila de tarefas executáveis sustentada durante o pico.
Execute o cenário várias vezes e registe o armazenamento em buffer, a latência das tarefas e a saturação da CPU. Utilize o pior resultado normal e repetível como base para o dimensionamento.
Separe as transcodificações por hardware das transcodificações por software
A aceleração por hardware pode transferir a conversão de vídeo para longe dos núcleos gerais da CPU, enquanto o fallback para software pode consumir muito mais CPU para o mesmo stream. A margem deve abranger o percurso que pode realmente ocorrer.
Um motor multimédia compatível pode processar várias transcodificações sem uma pressão equivalente sobre a CPU geral; os resultados de transcodificação por hardware do N100 fornecem um exemplo de baixo consumo.
Confirme que o painel apresenta o percurso de hardware pretendido para os seus ficheiros multimédia mais exigentes. Se o fallback for possível, inclua pelo menos um teste de transcodificação por software antes de considerar a margem segura.
Inclua as tarefas em segundo plano no pico
Análises, processamento, cópias de segurança e outro contentor podem sobrepor-se à reprodução, mesmo quando cada carga de trabalho é segura isoladamente. Os anfitriões partilhados precisam de um pico que inclua essas sobreposições.
A utilização simultânea de recursos faz parte da carga de trabalho real quando uma stack multimédia com vários serviços coloca vários serviços no mesmo anfitrião e nos mesmos caminhos de armazenamento.
Execute a reprodução mais exigente enquanto uma tarefa comum em segundo plano está ativa. Se essa sobreposição causar saturação contínua, reagende a tarefa ou reserve mais capacidade de computação. Converta o pico medido em requisitos de hardware para o Plex apenas depois de saber se o verdadeiro limite é a saturação da CPU, o fallback da transcodificação por hardware ou outra carga de trabalho partilhada.
Utilize um limiar de falha em vez de uma percentagem mágica
A margem útil é aquela que mantém o sistema abaixo do ponto em que a latência visível para o utilizador ou o trabalho em fila se tornam inaceitáveis. Esse limiar pode variar entre agregados familiares.
Uma segunda verificação de saturação após alterações à configuração confirma se o novo ponto de funcionamento repõe efetivamente a margem.
Defina uma condição de aprovação, como ausência de armazenamento em buffer, conclusão estável das tarefas e inexistência de uma fila de CPU contínua. Repita o teste após alterações importantes à biblioteca, aos clientes ou aos contentores, em vez de manter indefinidamente uma única percentagem.
Suporte e Dicas
Mais para Ler

Deve fazer uma cópia de segurança do Jellyfin em funcionamento ou parar primeiro o serviço?
Prefira cópias de segurança com o serviço parado, pela sua simplicidade; utilize instantâneos em funcionamento apenas quando o estado da aplicação for capturado de...

Porque é que o Jellyfin funciona a altas temperaturas ou faz ruído quando ninguém está a transmitir?
O calor em inatividade normalmente indica atividade em segundo plano ou uma carga de trabalho de um anfitrião partilhado; por isso, identifique o processo...

Quando deve reconstruir em vez de reparar o Jellyfin?
Escolha recriar em vez de reparar quando o problema for a divergência do ambiente de execução e o estado persistente estiver salvaguardado; não «recrie»...

