Como saber se o Jellyfin está limitado pelo processador, pela memória, pela rede ou pelo armazenamento?

Pode identificar o estrangulamento do Jellyfin repetindo uma carga de trabalho e associando o sintoma visível para o utilizador ao recurso que fica saturado, com erros ou em fila.

Um gráfico de CPU elevado não prova que a CPU é o limite, tal como o armazenamento ativo não prova que o armazenamento é a causa. Reutilize o mesmo ficheiro, cliente, qualidade e número de sessões, alterando uma condição de cada vez. Isto permite distinguir um verdadeiro limite de dependência de um caminho de reprodução mais exigente selecionado pelo cliente.

Mantenha o caso de reprodução constante

Escolha um ficheiro multimédia, um cliente, uma política de qualidade e um nível de simultaneidade. Registe se a sessão faz Reprodução direta, remultiplexação ou transcodificação antes de consultar os gráficos de recursos, porque o modo de reprodução determina quais os recursos que devem estar ocupados.

Comece pela reprodução direta para transcodificação, para conhecer o caminho do servidor antes de comparar o comportamento dos recursos.

Uma linha de base controlada impede que compare uma transcodificação num navegador com uma sessão de Reprodução direta nativa e atribua a diferença a um estrangulamento de hardware.

A CPU e a memória deixam assinaturas diferentes

O trabalho limitado pela CPU acompanha normalmente a descodificação por software, os filtros, a composição de legendas ou a codificação, enquanto a pressão sobre a memória surge como recuperação de memória, troca, trabalhadores bloqueados ou aumento da atividade de armazenamento causado pela paginação. Os sintomas podem sobrepor-se, mas os respetivos contadores são diferentes.

Utilize o método de utilização e saturação para inspecionar em conjunto a utilização, a saturação e os erros, em vez de usar a CPU ou a RAM média como veredito.

Se colocar um filtro em pausa ou mudar para descodificação por hardware restabelecer a velocidade em tempo real sem alterar o armazenamento ou a rede, o trabalho da CPU é provavelmente a causa. Se a recuperação de memória ou a troca desaparecer quando outro contentor é interrompido, a pressão sobre a memória é a explicação mais provável.

A rede e o armazenamento precisam de testes específicos ao caminho

Um carregamento de dados saturado pode fazer com que a reprodução remota fique em memória intermédia, enquanto a CPU do anfitrião permanece folgada. A latência do armazenamento pode atrasar o arranque, as procuras, os metadados e o espaço temporário da transcodificação, mesmo quando o débito sequencial parece suficiente. Teste o caminho que o cliente utiliza efetivamente.

Meça separadamente a latência e o débito do armazenamento e compare a mesma transmissão com as transferências concorrentes em pausa.

Se o sintoma acompanhar a profundidade da fila ou a utilização do carregamento de dados, alterar a CPU ou a RAM não o eliminará. Se o sintoma persistir depois de o caminho ficar inativo, avance para a compatibilidade do cliente ou para a capacidade de processamento.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Utilize uma matriz de decisão com quatro recursos

Em cada execução, registe o sintoma observável, o primeiro contador que fica saturado, se os erros aumentam e se a remoção da pressão sobre esse recurso restabelece a linha de base. Um único sinal positivo não é suficiente; a relação tem de se repetir.

Um teste de referência a frio e a quente compacto mantém a decisão centrada em evidências, em vez do impulso de atualizar o equipamento.

Pare quando um recurso explicar o sintoma em execuções repetidas. Se nenhum recurso o acompanhar, o problema ativo pode estar na interface do cliente, na ordem de arranque ou numa alteração do modo de reprodução fora do teste dos quatro recursos.