Como saber se o Plex está limitado pelo CPU, pela RAM, pelo armazenamento ou pela rede

Pode determinar o que limita o Plex reproduzindo uma carga de trabalho conhecida e procurando o recurso cuja pressão aumenta ao mesmo tempo que a transmissão fica mais lenta. Não atualize primeiro o componente que parece estar mais ocupado; uma utilização elevada só é relevante quando coincide com a falha de reprodução.

Comece com um ficheiro, um cliente, um modo de reprodução e um intervalo de tempo. Em seguida, separe o trabalho de conversão do Plex dos sinais do sistema operativo relativos ao CPU, à memória, ao armazenamento e à rede. O teste só está concluído quando alterar um recurso suspeito altera o sintoma original do Plex, mantendo estáveis as restantes condições.

Reproduza uma carga de trabalho do Plex antes de analisar as métricas do sistema

Escolha um ficheiro e um cliente que reproduzam o problema de forma fiável. Registe se o sintoma é um arranque lento, buffering repetido, uma transcodificação que fica para trás, uma análise que provoca atrasos na reprodução ou uma falha exclusiva do acesso remoto, porque cada sintoma aponta para um percurso de espera diferente.

Um fluxo de resolução de problemas específico do Plex deve começar pela sessão ativa, e não por um gráfico genérico do CPU. Uma verificação centrada no Dashboard separa os ramos de Reprodução direta, transcodificação, rede e armazenamento antes de começar a alterar o servidor.

Mantenha inalterados o ficheiro, as faixas selecionadas, a qualidade do cliente e a carga de trabalho simultânea enquanto recolhe as métricas do sistema. Se o sintoma variar entre testes, simplifique a carga de trabalho até a mesma falha se repetir; caso contrário, um pico posterior do CPU ou do disco poderá pertencer a outra tarefa.

Utilize a sessão do Plex para separar a entrega da conversão

Leia a sessão do Plex enquanto o problema ocorre. A Reprodução direta significa que o servidor está sobretudo a entregar os conteúdos multimédia armazenados, enquanto uma transcodificação de vídeo acrescenta um percurso de conversão em tempo real que pode deslocar o estrangulamento para o CPU ou para os motores de vídeo por hardware.

Utilize esse modo como uma ramificação, não como uma conclusão. Uma transcodificação que fica para trás torna o processamento um candidato forte, mas uma Reprodução direta com buffering mantém o armazenamento e a rede em consideração. Se o mesmo ficheiro mudar de modo quando as legendas, o áudio ou a qualidade forem alterados, reproduza novamente o problema com o pedido original antes de comparar as métricas do anfitrião.

O resultado desta secção deve ser um modo de reprodução fixo associado ao sintoma. Se não conseguir indicar se o teste que falha é Reprodução direta ou Transcodificação, pare aqui; comparar dados de RAM, disco e rede antes de estabilizar o percurso multimédia torna as métricas restantes mais difíceis de interpretar.

Teste a pressão sobre o CPU e a RAM em conjunto

Observe a utilização do CPU, a fila de execução ou a carga, a memória disponível e a atividade de swap durante o teste Plex fixo. A pressão sobre o CPU é mais significativa quando o processo do Plex ou o seu transcodificador consome capacidade de processamento de forma sustentada enquanto a saída fica para trás; a pressão sobre a memória é mais significativa quando o sistema começa a recuperar memória ou a utilizar swap e o tempo de resposta piora, mesmo que o CPU não seja o único recurso ocupado.

Um fluxo geral de análise do desempenho do Linux utiliza ferramentas como top, vmstat, iostat e sar para separar a pressão sobre os recursos. Em particular, CPU, memória, disco e rede exigem sinais de saturação diferentes, em vez de um único número de utilização geral.

Se o CPU permanecer próximo do limite apenas durante a transcodificação que falha e a transmissão recuperar quando a conversão for removida ou acelerada, trate o processamento como o principal estrangulamento. Se, em vez disso, aumentarem a utilização de swap ou a recuperação de memória, reduza as tarefas simultâneas que consomem muita memória ou adicione memória e, em seguida, repita a mesma carga de trabalho do Plex antes de alterar as definições de armazenamento ou rede.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Teste o armazenamento com o mesmo percurso multimédia

Para testar o armazenamento, leia o mesmo conteúdo multimédia a partir do mesmo sistema de ficheiros enquanto o sintoma se reproduz e observe a latência do dispositivo, o enfileiramento e a espera de E/S. Capacidade e desempenho são aspetos distintos: um disco pode ter espaço livre e, ainda assim, responder lentamente porque outra tarefa está a gerar E/S aleatória ou porque o percurso multimédia passa por um conjunto de armazenamento ocupado ou por uma montagem de rede.

Ferramentas do Linux como iostat e iotop são úteis porque a espera de E/S do disco e o débito do dispositivo revelam um modo de falha diferente do CPU elevado ou da atividade de swap. Compare esses valores com o intervalo exato de buffering, e não com uma média em estado inativo.

Se o ficheiro for lido sem problemas enquanto o Plex apresenta buffering, o armazenamento torna-se menos provável. Se a latência e o enfileiramento aumentarem juntamente com o sintoma, pause a tarefa concorrente do disco ou mova o ficheiro de teste para um percurso local comprovadamente rápido; se o Plex recuperar imediatamente no mesmo modo de reprodução, o armazenamento terá passado de suspeita a evidência.

Teste o débito da rede no percurso real

Teste separadamente o percurso entre o servidor e o cliente, sem depender do Plex. Um cliente local ligado por cabo pode distinguir um problema no percurso remoto de um problema de recursos em todo o servidor, enquanto um teste de débito de ponta a ponta pode mostrar se o percurso consegue suportar a taxa dos conteúdos multimédia sem depender da aplicação Plex.

Utilize uma ferramenta como iperf3 quando controlar ambas as extremidades. Um teste de rede deve analisar o débito, a perda de pacotes e a latência, porque a velocidade anunciada da ligação não prova que o percurso real fornece tráfego de aplicação estável.

Se o teste de rede independente colapsar enquanto o CPU, a memória e o armazenamento permanecerem saudáveis, corrija o percurso antes de ajustar o transcodificador. Se a rede tiver uma margem sustentada confortável e o sintoma do Plex persistir num teste local com ligação por cabo, volte ao ramo dos recursos do servidor em vez de comprar um router mais rápido.

Altere apenas o recurso que falhou no teste

Escolha o primeiro recurso que falhou num teste discriminador e faça uma alteração que deva afetar apenas esse ramo. Os exemplos incluem ativar uma transcodificação por hardware verificada para uma transmissão limitada pelo processamento, reduzir uma tarefa em segundo plano que consuma muita memória, reagendar uma tarefa intensiva para o disco ou contornar um segmento de rede problemático.

Para um acompanhamento específico do Plex, o percurso de diagnóstico do buffering da ZimaSpace oferece uma continuação mais aprofundada quando souber se precisa de alterar o modo de reprodução, a carga de conversão, a estabilidade da rede ou a capacidade de resposta do armazenamento.

Repita o ficheiro, o cliente e o modo de reprodução originais depois da alteração. Considere um componente como o estrangulamento apenas quando o sintoma original melhorar e o sinal de pressão correspondente diminuir ou ganhar margem. Se o sintoma não mudar, reponha a configuração de referência e teste o ramo seguinte, em vez de acumular atualizações até a verdadeira causa desaparecer por acaso.