Que limite de memória deve definir para o Jellyfin?

Não escolha um limite de memória universal para o Jellyfin; comece por uma carga de trabalho medida, reserve memória para o anfitrião e para os contentores vizinhos e só aplique um limite rígido depois de observar os picos reais.

O seu contentor cresce até o anfitrião começar a usar swap, ou um limite baixo provoca repetidos encerramentos por falta de memória (OOM)? Meça a utilização em inatividade, as análises da biblioteca, o processamento de metadados, as transcodificações simultâneas e a memória disponível para o Docker ou para a máquina virtual antes de alterar o limite. Um limite só é seguro quando a carga de trabalho original continua a ser concluída e o anfitrião mantém margem para recuperação.

Separe o crescimento normal da cache da pressão sobre a memória residente

Primeiro, compare a RSS do contentor, a cache, a swap e a memória livre do anfitrião durante a inatividade e durante a tarefa repetível mais exigente. A cache do sistema de ficheiros pode parecer grande sem indicar uma fuga de memória, enquanto o crescimento da memória residente acompanhado de eventos OOM indica uma limitação real.

Uma implementação básica do Jellyfin em Docker começa normalmente com alguns gigabytes e precisa de mais memória para transcodificação, mas o valor correto depende da carga de trabalho (referência de memória baseada na carga de trabalho).

Se a RSS permanecer estável enquanto a cache aumenta e o anfitrião tiver memória que possa ser recuperada, monitorize em vez de apertar o limite. Se a RSS aumentar juntamente com a utilização de swap ou mensagens de encerramento por OOM, avance para os testes de transcodificação e da biblioteca.

Teste o limite sob o acionador que provoca a falha

Execute uma análise da biblioteca, uma transcodificação representativa e o número esperado de transmissões simultâneas, registando a utilização de memória do cgroup, os eventos de memória, a swap e a pressão sobre o anfitrião. Altere apenas o limite de memória entre os testes.

Um limite que permite a reprodução em inatividade, mas falha durante legendas, conversão HDR ou indexação, não é uma configuração de produção válida. Registe o acionador que causou a falha para não aumentar o limite devido a um estrangulamento não relacionado.

Se o contentor for encerrado, aumente o limite apenas depois de reduzir a cache de transcodificação desnecessária ou separar as tarefas pesadas. Se o próprio anfitrião começar a usar swap, reduza a simultaneidade ou transfira uma função; atribuir ao Jellyfin toda a RAM restante apenas transfere a falha para outro serviço.

Defina um limite de paragem e verifique a persistência

Mantenha um alerta de nível baixo abaixo do limite rígido e deixe memória suficiente para o anfitrião, os serviços de armazenamento e um reinício limpo. Um limite rígido deve proteger o anfitrião, não ocultar um processo sem limites ou uma máquina subdimensionada.

Depois de alterar o limite, pare e recrie o contentor uma vez e repita a análise original e o acionador de reprodução. Confirme que o limite configurado continua ativo depois da recriação e que a base de dados permanece editável.

Pare de ajustar e escale o problema quando os eventos OOM continuarem num limite que não deixa margem para o anfitrião, a base de dados ficar corrompida ou o processo crescer sem uma carga de trabalho reproduzível. Preserve os registos e a última configuração conhecida como funcional antes de efetuar uma alteração maior.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifique novamente a reprodução de pico após um reinício a frio

Reinicie o anfitrião, aguarde que as montagens de armazenamento e os contentores vizinhos estejam prontos e reproduza a mesma combinação de transmissões multiutilizador que originalmente expôs o limite. Não valide apenas com um painel em inatividade ou uma única sessão de Reprodução direta.

A recuperação está comprovada quando a reprodução permanece estável, não surge uma tempestade de swap, o contentor se mantém abaixo do limite e uma nova cópia de segurança ou reinício é concluída sem erros relacionados com a memória. Compare o resultado com a referência registada antes do ajuste.

Mantenha a configuração quando a carga de trabalho de pico for concluída com uma margem mensurável no anfitrião. Se falhar apenas depois de outro contentor arrancar, divida o orçamento de recursos ou reagende a tarefa concorrente em vez de aumentar novamente o limite do Jellyfin.