Como a localização da base de dados afeta a fiabilidade e a recuperação do Plex

A fiabilidade do Plex melhora geralmente quando a base de dados ativa e os metadados permanecem num armazenamento local de baixa latência, enquanto os ficheiros multimédia maiores podem ficar noutro local.

Um servidor Plex pode transmitir filmes a partir de discos rígidos de grande capacidade ou de armazenamento de rede, enquanto os dados da aplicação executam muitas leituras e escritas pequenas através de um caminho diferente. Esta distinção é importante porque um ficheiro multimédia é composto sobretudo por dados sequenciais, enquanto a base de dados da biblioteca, os metadados, as miniaturas e os registos funcionam mais como o estado da aplicação. Pense na localização da base de dados como uma decisão de latência e recuperação, não de capacidade.

Porque É Que a Base de Dados do Plex Se Comporta de Forma Diferente dos Ficheiros Multimédia

O diretório de dados do Plex contém a base de dados da biblioteca, além de metadados, imagens, caches e outros dados do estado do servidor. Estes ficheiros são acedidos durante a navegação, as análises, o processamento de metadados, as atualizações do estado de reprodução e a manutenção. Por isso, picos de latência no caminho dos dados da aplicação podem fazer com que todo o servidor pareça pouco fiável, mesmo quando os próprios ficheiros de filmes são lidos rapidamente.

O Plex mantém o estado da biblioteca acedido com frequência numa base de dados SQLite, pelo que a latência e a integridade da base de dados devem ser avaliadas separadamente do débito do armazenamento multimédia; esse é o ponto de partida para estabelecer a localização e a recuperação da base de dados.

O padrão observável é simples: se a navegação, as atualizações da biblioteca e o arranque forem lentos, mas a Reprodução Direta de um ficheiro já aberto funcionar bem, o caminho dos dados da aplicação deve ser analisado antes dos discos multimédia.

Meça a Latência e a Recuperação, Não Apenas o Débito

As variáveis importantes são a latência de E/S aleatória, a estabilidade do sistema de ficheiros, o espaço livre, a durabilidade das escritas e o comportamento das cópias de segurança. O débito sequencial máximo é secundário, porque a base de dados não se comporta como um grande fluxo de vídeo.

Ao medir a localização e a recuperação da base de dados, uma verificação de estrangulamentos recurso a recurso deve analisar a utilização, a saturação e os erros na CPU, na memória, na rede e no armazenamento, em vez de depender de uma única métrica média.

Se a mudança dos dados da aplicação reduzir o tempo de arranque e as pausas durante as análises sem alterar o débito da reprodução multimédia, isolou um estrangulamento nos metadados/base de dados, e não no armazenamento multimédia.

Quando É Que um Armazenamento Mais Rápido Deixa de Ajudar

Um SSD local não resolve uma transcodificação limitada pela CPU, uma largura de banda de carregamento saturada, codecs não suportados pelo cliente ou um disco multimédia com falhas. Quando a latência da base de dados é suficientemente baixa para que estas outras etapas passem a dominar, mais IOPS no dispositivo dos dados da aplicação proporciona benefícios cada vez menores.

No limite de falha da localização e recuperação da base de dados, quando existe corrupção real, a recuperação é mais segura se criar uma nova base de dados SQLite limpa a partir dos dados recuperáveis, em vez de modificar repetidamente o original danificado.

O teste de limite consiste em comparar a integridade da base de dados e o espaço livre com o momento em que o sintoma ocorre. Se a integridade estiver correta e a latência dos dados da aplicação for baixa, passe a investigação para a CPU, a rede, a compatibilidade do cliente ou o caminho dos ficheiros multimédia, em vez de voltar a atualizar o armazenamento.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Utilize um Teste de Localização em Quatro Passos

Mantenha o caminho dos dados da aplicação Plex num sistema de ficheiros local persistente, mantenha uma cópia de segurança atualizada e trate os ficheiros multimédia maiores como um nível de capacidade separado. Em seguida, faça uma medição de uma ação repetível da biblioteca antes e depois de qualquer alteração de localização. Uma organização do armazenamento de um servidor multimédia doméstico é mais fácil de avaliar quando as funções de computação, dados da aplicação, armazenamento multimédia e rede são registadas separadamente.

Antes de aceitar uma alteração à localização e recuperação da base de dados, uma cópia de segurança consistente do SQLite deve ser criada através de um fluxo seguro de cópia de segurança ou instantâneo, e não através de uma cópia descontrolada dos ficheiros ativos da base de dados durante as escritas.

Pare de otimizar o dispositivo da base de dados quando o teste repetido deixar de alterar o comportamento do arranque, da navegação ou das análises. Nessa altura, a medição seguinte mais útil é a etapa que continua a consumir tempo com a mesma carga de trabalho.

1. Confirme que o diretório de dados do Plex é persistente e dispõe de espaço livre
2. Meça o arranque e uma análise da biblioteca antes de alterar o armazenamento
3. Mova apenas os dados da aplicação, e não todos os ficheiros multimédia, para fazer a comparação
4. Verifique os caminhos de cópia de segurança e restauro antes de desativar a localização antiga