Até que tamanho pode crescer uma biblioteca Jellyfin num único anfitrião?

Não existe um limite universal útil para o número de itens do Jellyfin que indique quando um anfitrião está “cheio”. O limite prático é atingido quando a base de dados, a memória, o armazenamento, as tarefas agendadas ou a reprodução simultânea deixam de cumprir o seu objetivo de tempo de resposta.

Duas bibliotecas com o mesmo número de filmes podem sobrecarregar um servidor de formas muito diferentes, porque a densidade dos metadados, as imagens dos capítulos, os dados trickplay, o armazenamento em rede, a combinação de clientes e as necessidades de transcodificação variam. Meça o anfitrião com a sua carga de trabalho real e defina um limite que possa voltar a testar após cada grande expansão da biblioteca.

Comece pela Ocupação da Base de Dados, Não pelo Número de Ficheiros Multimédia

O Jellyfin armazena o estado da biblioteca na base de dados, enquanto os ficheiros multimédia permanecem no sistema de ficheiros. À medida que o catálogo cresce, a primeira métrica útil é o tamanho e o comportamento do conjunto de dados do Jellyfin, e não o total de terabytes dos ficheiros de filmes.

A documentação de armazenamento do Jellyfin refere que a base de dados de uma biblioteca de tamanho moderado pode atingir aproximadamente 10 a 100 GB e recomenda mantê-la num armazenamento local, em vez de numa partilha de rede. orientações sobre o armazenamento da base de dados

Registe o tamanho da base de dados, o espaço livre no volume de dados e o tempo necessário para abrir vistas de bibliotecas grandes ou pesquisar depois de a cache estar aquecida. Se estes valores permanecerem estáveis enquanto a capacidade multimédia cresce, o tamanho bruto dos ficheiros multimédia, por si só, ainda não ultrapassou o limite de um único anfitrião.

Meça a Memória Disponível Depois de a Base de Dados Aquecer

O comportamento da memória é mais importante nas versões atuais do Jellyfin, porque o servidor pode manter uma grande quantidade de dados da base de dados em memória para reduzir as leituras do disco. Assim, um anfitrião que parecia confortável com um catálogo menor pode apresentar uma utilização estável de RAM mais elevada depois de a biblioteca crescer.

As notas de lançamento do Jellyfin 10.11 explicam que o motor da base de dados coloca agressivamente os metadados em cache na memória e pode utilizar memória até ao tamanho da base de dados da biblioteca, libertando-a quando outros processos precisam dela. colocação da base de dados em cache na memória

Observe a memória disponível e a atividade de swap depois de a navegação normal ter aquecido a cache. O sinal de alerta não é a utilização elevada da cache por si só; é a pressão sustentada sobre a memória, a utilização de swap ou a latência que surge quando o Jellyfin compete com outros contentores e desaparece quando essa competição é removida.

Cronometre o Trabalho em Segundo Plano que Cresce com a Biblioteca

As análises da biblioteca, a atualização de metadados, a extração de imagens, o processamento de legendas e outras tarefas agendadas podem tornar-se o primeiro limite de escala, mesmo quando a reprodução continua fluida. Meça a duração dessas tarefas e verifique se coincidem com as horas em que as pessoas utilizam efetivamente o servidor.

A extração de imagens dos capítulos é um exemplo de um custo de escalabilidade documentado diretamente pelo Jellyfin: ativar a extração durante uma análise da biblioteca pode tornar as análises significativamente mais lentas, sobretudo em bibliotecas grandes. custo da análise de imagens dos capítulos

Se uma análise completa ocupa agora a maior parte da janela de manutenção, comece por reduzir o trabalho desnecessário ou por transferir as tarefas dispendiosas para fora das horas de maior utilização. Uma análise mais longa não significa automaticamente que o anfitrião tenha capacidade insuficiente; torna-se um problema de capacidade quando a manutenção colide repetidamente com a utilização interativa ou nunca termina de forma fiável.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Separe a Escala da Biblioteca da Escala da Transcodificação

Um catálogo enorme não torna necessariamente dispendiosa uma transmissão em reprodução direta, enquanto um catálogo pequeno pode sobrecarregar um CPU quando vários clientes incompatíveis solicitam transcodificação de vídeo. Trate a escala do catálogo e a conversão durante a reprodução como testes de capacidade separados.

Execute um teste de reprodução repetível com a combinação de clientes que realmente utiliza: uma transmissão em reprodução direta, uma transcodificação típica e, em seguida, o pico de simultaneidade previsto. Se o catálogo crescer, mas estes testes de reprodução permanecerem inalterados, não atingiu um limite de transcodificação devido ao tamanho da biblioteca.

Quando a saturação do CPU ocorre apenas durante a transcodificação, ajuste os codecs, a aceleração por hardware ou a compatibilidade dos clientes antes de culpar a base de dados. O guia de aceleração por hardware é um passo seguinte mais relevante do que transferir uma base de dados de metadados saudável para um segundo servidor.

Verifique a Latência do Armazenamento e a Disponibilidade dos Conteúdos Durante as Análises

As bibliotecas grandes abrangem frequentemente vários discos ou um NAS, pelo que o caminho até aos conteúdos pode tornar-se a camada limitadora. Compare a navegação interativa e a reprodução com e sem uma análise da biblioteca em execução e observe a fila do disco ou a latência da partilha de rede no caminho dos conteúdos.

O Jellyfin recomenda montar o armazenamento Samba ou NFS diretamente no sistema operativo e alerta para o facto de a manutenção agendada poder remover itens da biblioteca se o armazenamento estiver indisponível quando uma tarefa for executada. armazenamento de rede e precauções de manutenção

Se a base de dados for rápida, mas os diretórios multimédia desaparecerem intermitentemente ou as análises de metadados ficarem bloqueadas numa partilha lenta, adicionar CPU não resolverá o verdadeiro estrangulamento. Corrija primeiro a fiabilidade da montagem, a latência do armazenamento ou o agendamento das tarefas e, em seguida, repita o mesmo teste.

Defina o Seu Próprio Limite de um Único Anfitrião com um Teste Repetível

Crie uma pequena folha de avaliação antes da próxima expansão da biblioteca: latência de pesquisa com a cache aquecida, tempo para abrir uma coleção grande, duração de uma análise completa, tamanho da base de dados, RAM disponível, latência máxima do armazenamento e um teste representativo de reprodução simultânea. Utilize sempre as mesmas medições.

Um fluxo de trabalho de centro multimédia doméstico já separa o armazenamento multimédia da camada da aplicação Jellyfin; mantenha essa separação no seu teste para saber se a lentidão vem do anfitrião, do caminho de armazenamento ou dos clientes.

Considere que um único anfitrião deixou de ser suficiente apenas quando um objetivo medido falha repetidamente após ajustes de baixo risco: os pedidos interativos continuam lentos, as análises não conseguem terminar dentro da janela de manutenção, a pressão sobre a memória provoca utilização de swap, a latência do armazenamento não pode ser isolada ou as transcodificações necessárias excedem a capacidade computacional disponível. Nessa altura, as evidências indicam qual o recurso que deve expandir, em vez de o obrigarem a definir um limite arbitrário de número de itens.