Porque é que as leituras e escritas do Plex criam cargas diferentes no servidor

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.

O Plex lê e escreve em partes diferentes de um servidor doméstico, porque as grandes transferências de multimédia e as pequenas atualizações de estado têm padrões de E/S muito diferentes.

Uma transmissão pode ler sequencialmente um ficheiro grande enquanto o Plex atualiza simultaneamente bases de dados, registos, metadados ou dados temporários em operações mais pequenas. Estes fluxos podem partilhar um dispositivo e, ainda assim, responder de forma diferente à carga. Meça separadamente o débito da multimédia e a latência dos dados da aplicação antes de concluir que a “utilização do disco” é a causa.

As leituras de multimédia são normalmente orientadas para o débito

A reprodução direta obtém grandes quantidades contíguas de dados multimédia e precisa principalmente de um débito sustentado, com margem suficiente para transmissões simultâneas. A latência de procura é menos importante do que numa base de dados cheia de registos pequenos.

Um armazenamento mais rápido só ajuda quando a sua latência, capacidade e perfil de transações se adequam à carga de trabalho; as vantagens e desvantagens do armazenamento de dados ativos tornam o padrão de acesso mais útil do que a velocidade nominal do dispositivo, por si só.

Meça o débito agregado de leitura da multimédia durante a combinação de transmissões mais exigente. Se permanecer muito abaixo da capacidade do dispositivo e da rede, mover apenas a multimédia para um armazenamento flash mais rápido dificilmente resolverá um atraso nos metadados ou na base de dados.

As escritas dos dados da aplicação são mais sensíveis à latência

As transações da base de dados, as atualizações de capas, os registos e os metadados geram escritas mais pequenas que podem ficar à espera de sincronização, journaling ou E/S aleatórias concorrentes. O seu custo visível pode ser elevado mesmo quando o débito total em MB/s é baixo.

O Linux pode acumular e descarregar páginas sujas em rajadas, pelo que a escrita diferida pode separar o momento em que o Plex escreve do momento em que o dispositivo apresenta um pico.

Acompanhe a latência, a profundidade da fila, a memória suja e o dispositivo dos dados da aplicação independentemente do dispositivo da multimédia. Uma carga de trabalho de pequenas escritas com latência elevada é um problema diferente de uma leitura sequencial de multimédia que saturou o dispositivo.

As leituras e escritas concorrentes podem interferir

Colocar o estado da base de dados, a multimédia, as cópias de segurança e os descarregadores no mesmo dispositivo permite que padrões de acesso não relacionados concorram pela mesma fila. Uma unidade rápida isoladamente pode parecer inconsistente quando estas tarefas se sobrepõem.

O desempenho da base de dados varia tanto com a velocidade do armazenamento como com a combinação de cargas de trabalho, e o comportamento da base de dados sensível à E/S é uma das razões para testar a carga de trabalho combinada, em vez de extrapolar a partir de um único teste de cópia de ficheiros.

Repita uma ação lenta do Plex com as cópias de segurança e os processos de gestão de multimédia em pausa. Se a latência diminuir drasticamente, separe os horários ou as funções de armazenamento antes de substituir o servidor inteiro.

A separação de funções torna o estrangulamento visível

Uma topologia organizada atribui ao estado persistente do Plex, à multimédia em volume, ao trabalho temporário e às cópias de segurança funções distintas de desempenho e recuperação, mesmo quando alguns partilham hardware físico. Isso torna os testes posteriores interpretáveis.

A separação de funções também facilita atribuir a saturação dos recursos ao dispositivo ou caminho que efetivamente realiza o trabalho, em vez de a atribuir ao armazenamento como um conjunto indiferenciado.

Volte a testar após cada alteração de função e mantenha apenas as alterações que deslocarem o estrangulamento medido. Numa topologia de servidor multimédia doméstico, o estado, a multimédia, o trabalho temporário e as cópias de segurança devem permanecer suficientemente distintos para serem medidos de forma independente.

Centro de Tecnologia e IA

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.