Quantos utilizadores e tarefas em segundo plano deve suportar um servidor Jellyfin?

A capacidade de um servidor Jellyfin não deve ser dimensionada apenas com base nos utilizadores registados. Uma família com oito contas pode gerar menos carga do que dois utilizadores remotos a transcodificar vídeo 4K enquanto decorrem, em segundo plano, uma verificação da biblioteca, uma tarefa de legendas e uma cópia de segurança. A pergunta relevante sobre a capacidade é quanta carga de trabalho simultânea, em primeiro e segundo plano, o servidor consegue suportar antes de a reprodução ou a administração deixarem de cumprir os objetivos definidos.

Elabore um orçamento de carga de trabalho que inclua sessões de reprodução, transcodificações, tarefas agendadas, atividade de armazenamento e serviços alojados em conjunto. Depois, teste a sobreposição normal mais exigente e deixe de aumentar a carga quando o primeiro recurso partilhado começar a formar filas persistentes ou a apresentar erros ou atrasos percetíveis para os utilizadores.

Traduza os utilizadores em cargas de trabalho de reprodução

Conte separadamente as sessões de reprodução direta, remux, conversão de áudio e transcodificação de vídeo. Os clientes Jellyfin comunicam os codecs, as resoluções, as taxas de bits e as limitações que suportam, pelo que dois utilizadores a verem a mesma fonte podem exigir ao servidor cargas de trabalho muito diferentes.

As políticas dos utilizadores do Jellyfin também podem alterar a carga do servidor. Os controlos atuais de gestão de utilizadores permitem autorizar ou restringir o acesso remoto, a reprodução de conteúdos multimédia, a transcodificação e a largura de banda da Internet por transmissão. Por isso, o número de utilizadores só é útil depois de ser traduzido nas permissões e nos modos de reprodução previstos para o mesmo momento.

Comece pela combinação mais exigente de uma noite normal, em vez de pelo número máximo teórico de contas. Se, normalmente, a família tiver duas sessões locais de reprodução direta e uma conversão remota, essa é a carga de base que o servidor tem de suportar sem dificuldade.

Inclua as tarefas agendadas no mesmo orçamento de capacidade

O Jellyfin executa tarefas mesmo quando ninguém carrega em Reproduzir. As verificações da biblioteca, as transferências de legendas, a limpeza da cache, as atualizações de plugins, a extração de imagens dos capítulos, a otimização da base de dados e as tarefas de geração de conteúdos multimédia podem coincidir com a visualização.

A lista atual de tarefas agendadas mostra que o Jellyfin pode executar verificações, extração de imagens, atualizações de plugins, manutenção da base de dados, tarefas de legendas, limpeza da cache e outros trabalhos em segundo plano. Os plugins podem adicionar mais tarefas.

Não dimensione o servidor com base num teste de reprodução silenciosa e depois deixe todas as tarefas pesadas serem executadas durante o mesmo pico. Adie primeiro os trabalhos que podem esperar para fora do período de visualização; inclua os trabalhos que têm de coincidir no teste de produção.

Identifique o primeiro recurso partilhado que perde margem

Um anfitrião pode falhar devido à capacidade do motor multimédia, à CPU, à memória, à latência do SSD, à pressão das operações de procura no HDD, à largura de banda da rede ou a uma dependência. Mais núcleos de CPU não ajudam quando a ligação de envio remota está saturada, e mais RAM não resolve uma transcodificação que a GPU selecionada não consegue acelerar.

A análise da ZimaSpace sobre a capacidade do Jellyfin num pequeno servidor doméstico utiliza o mesmo modelo centrado na carga de trabalho: a procura simultânea e o primeiro recurso a saturar são mais importantes do que um limite baseado no número de contas.

Meça a velocidade de transcodificação, a saturação da CPU ou do motor multimédia, a pressão sobre a memória, a latência do armazenamento e a velocidade de transferência da rede durante a sobreposição exata. O recurso limitador é aquele cuja pressão aumenta quando ocorre a falha e diminui quando essa pressão é eliminada.

Featured

ZimaBoard 2 - Mini servidor doméstico para a sua grande ideia

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Impeça que o trabalho de fundo consuma a margem de capacidade interativa

A reprodução tem um prazo: o segmento seguinte tem de chegar antes de o buffer do cliente esvaziar. Uma análise da biblioteca pode normalmente terminar mais tarde sem prejudicar ninguém. Esta diferença deve orientar o agendamento e as políticas de recursos.

Reserve margem suficiente para que o início ou a procura normal de uma reprodução continue a responder enquanto prossegue o trabalho de fundo inevitável. Se uma otimização da base de dados ou uma tarefa de análise multimédia causar interrupções na reprodução, agende-a de outra forma ou limite a tarefa antes de comprar um servidor maior.

Num anfitrião partilhado, repita o teste com outros contentores ativos. Um gestor de transferências, um indexador de fotografias, um motor de cópias de segurança ou um processo de IA local pode reduzir a capacidade do Jellyfin, mesmo que a carga de trabalho do próprio Jellyfin não tenha mudado.

Use uma matriz de cargas de trabalho em vez de um limite de utilizadores

Apresente a capacidade como uma carga de trabalho testada, por exemplo, «três transmissões representativas mais uma análise agendada mantêm-se dentro do objetivo», e não «este servidor suporta dez utilizadores». Esse resultado pode ser reproduzido quando a biblioteca, os clientes e a utilização doméstica mudarem.