Porque é que o consumo de memória do Plex continua elevado depois de concluído o trabalho?
O consumo de memória do Plex pode continuar elevado depois de uma tarefa terminar, porque o Linux mantém uma cache de sistema de ficheiros reutilizável e as aplicações conservam memória alocada para trabalhos futuros.
Uma memória “utilizada” elevada não é automaticamente uma fuga de memória. Compare a memória residente dos processos, a cache recuperável, a pressão de swap e se o anfitrião devolve memória quando outra carga de trabalho precisa dela. Investigue apenas quando o consumo continuar a crescer ao longo de ciclos repetidos ou causar pressão e instabilidade reais.
Separe a Memória dos Processos da Cache do Sistema de Ficheiros
O Linux utiliza a RAM que estaria inativa para armazenar em cache ficheiros e páginas de bases de dados, o que pode fazer com que os valores de memória livre pareçam baixos depois de análises ou reproduções. A cache recuperável é diferente de um crescimento irrecuperável da aplicação.
A RAM utilizada, por si só, é um indicador fraco de fuga de memória, porque a cache do Linux versus a memória da aplicação pode permanecer elevada mesmo quando a memória ainda é recuperável.
Registe o RSS do Plex, a cache do anfitrião, a memória disponível e a swap antes e depois da carga de trabalho. Se a memória disponível permanecer saudável, não faça ajustes apenas para maximizar a coluna de memória livre.
Uma Cache Aquecida Pode Ser Útil Depois de o Trabalho Terminar
Manter os metadados e as páginas da base de dados residentes pode tornar a navegação posterior mais rápida. A cache deve ser avaliada com base na capacidade de o kernel a recuperar sob pressão, e não por voltar imediatamente a zero.
As páginas em cache podem continuar a ser úteis até que uma procura concorrente altere o seu valor, de acordo com o comportamento normal da cache de páginas do Linux.
Inicie uma carga de trabalho controlada que consuma memória e observe se a cache diminui antes de ocorrer swapping ou de os processos serem terminados. Uma recuperação saudável confirma a explicação baseada na cache.
Procure Crescimento ao Longo de Ciclos Repetidos
Uma fuga de memória real costuma manifestar-se como um consumo de memória do processo que continua a aumentar durante a mesma carga de trabalho concluída e não estabiliza. Um patamar elevado após uma análise extensa não constitui prova suficiente.
Acompanhe a utilização e a saturação ao longo de vários ciclos idênticos, para que a pressão de memória seja associada a uma carga de trabalho repetível e não a uma única observação.
Execute a mesma tarefa da biblioteca três vezes e registe o RSS do Plex depois de este estabilizar em cada execução. Só avance para uma investigação mais aprofundada se a linha de base estabilizada continuar a subir ou se o anfitrião começar a recuperar memória de forma deficiente. Avalie a memória na topologia mais ampla do servidor multimédia doméstico, porque a cache de páginas, os serviços complementares e o comportamento do armazenamento podem alterar a linha de base estabilizada saudável.
Os Contentores Partilhados Podem Alterar a Interpretação
Outro serviço pode consumir cache ou provocar swapping, fazendo com que o Plex pareça responsável por um problema de memória de todo o anfitrião. Inspecione a máquina inteira antes de definir um limite inferior para o Plex.
Os anfitriões com vários serviços criam dependências entre contentores partilhados em torno da mesma memória física, mesmo quando os processos estão isolados.
Repita a carga de trabalho com o maior contentor complementar pausado. Se a pressão de memória desaparecer, ajuste primeiro o orçamento partilhado do anfitrião, antes de alterar o próprio Plex.
Produtos recomendados
Suporte e Dicas
Mais para Ler
Deve fazer uma cópia de segurança do Jellyfin em funcionamento ou parar primeiro o serviço?
Prefira cópias de segurança com o serviço parado, pela sua simplicidade; utilize instantâneos em funcionamento apenas quando o estado da aplicação for capturado de...
Porque é que o Jellyfin funciona a altas temperaturas ou faz ruído quando ninguém está a transmitir?
O calor em inatividade normalmente indica atividade em segundo plano ou uma carga de trabalho de um anfitrião partilhado; por isso, identifique o processo...
Quando deve reconstruir em vez de reparar o Jellyfin?
Escolha recriar em vez de reparar quando o problema for a divergência do ambiente de execução e o estado persistente estiver salvaguardado; não «recrie»...
