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

Não defina um limite de memória para o Immich com base num número universal de GB. Um objetivo de RAM ao nível do anfitrião e um limite por contentor resolvem problemas diferentes: o anfitrião tem de suportar toda a stack, enquanto o limite do contentor deve proteger o anfitrião sem impedir uma carga de trabalho legítima do Immich.

Navegar numa biblioteca processada pode parecer pouco exigente, mas um arranque a frio do processamento de aprendizagem automática, uma importação grande, a geração de miniaturas, a análise facial ou o processamento de vídeo podem consumir muito mais memória. Meça a carga de trabalho mais pesada de que realmente necessita, mantenha margem para o PostgreSQL e para o sistema operativo e trate os encerramentos OOM repetidos como um limite mal definido, não como uma limitação normal.

Meça a Pressão da Memória Antes de Escolher o Limite

Registe a memória em três estados: navegação tranquila, um carregamento diário representativo e a carga de trabalho em segundo plano mais pesada prevista. Recolha a utilização do contentor, a memória disponível no anfitrião, a atividade de swap, os eventos OOM e se as tarefas continuam a progredir. Um único pico de docker stats não é suficiente, porque a contabilização de memória do Linux inclui vários tipos de memória com comportamentos de recuperação diferentes.

Uma análise detalhada da memória cgroup do Docker útil separa a memória anónima, a cache baseada em ficheiros e o slab, em vez de tratar o total bruto como igualmente perigoso. Uma cache de ficheiros estável, com margem saudável no anfitrião, é diferente de uma memória anónima que aumenta continuamente, de pressão de swap ou de um contador OOM do cgroup que aumenta durante a mesma tarefa do Immich.

Considere esta etapa concluída quando conseguir identificar um valor máximo repetível e explicar se é composto sobretudo por cache recuperável ou por memória de trabalho ativa. Se a utilização continuar a aumentar durante uma carga de trabalho inalterada, se um contentor for repetidamente terminado por OOM ou se o anfitrião começar a usar swap intensivamente, pare de dimensionar com base nessa execução e diagnostique primeiro o crescimento anormal.

Dimensione o Limite em Torno da Carga de Trabalho Legítima Mais Pesada do Immich

Escolha a carga de trabalho que tem de continuar suportada depois de aplicar o limite. Para uma família, isso pode significar quatro telemóveis a carregar fotografias enquanto as tarefas de Pesquisa Inteligente e de reconhecimento facial terminam; para outra, pode ser uma grande importação inicial seguida de navegação normal. Mantenha o conjunto de dados, as definições dos modelos, a concorrência e os outros contentores inalterados durante as medições, para que o limite reflita um compromisso de serviço definido.

Defina o limite rígido acima do pico não recuperável observado, com margem mensurável suficiente para picos breves, preservando simultaneamente memória do anfitrião para o PostgreSQL, a cache do sistema de ficheiros, o runtime de contentores e os serviços não relacionados. A lista de verificação da ZimaSpace sobre sinais de alerta de recursos para IA local é útil, porque o calor, a utilização de swap e os reinícios súbitos revelam uma tensão ao nível do anfitrião que um gráfico apenas do Immich pode não mostrar. Não interprete “o contentor atingiu o limite uma vez” como prova de que é necessária mais RAM. O limite de falha importante é saber se a mesma carga de trabalho legítima abranda drasticamente, perde tarefas, utiliza swap continuamente ou é terminada por OOM. Por outro lado, um limite é demasiado permissivo se o Immich conseguir privar a base de dados ou o anfitrião antes de o próprio cgroup se tornar o limite.

Reduza a Carga de Trabalho Antes de Aumentar o Limite por Causa de Crescimento Anormal

Se o limite proposto falhar apenas durante uma classe de tarefas em segundo plano, reduza a concorrência dessa tarefa ou isole a etapa antes de aumentar o limite máximo. A aprendizagem automática, a geração de miniaturas, o processamento de vídeo e as tarefas da base de dados podem ter perfis de memória diferentes. Um lote ativo mais pequeno pode demorar mais tempo, mas manterá a interface doméstica responsiva e o anfitrião recuperável.

As falhas específicas de cada versão também são importantes. Um relatório de memória do Immich v3.0.3 descreveu um trabalhador de aprendizagem automática que crescia até um limite cgroup provocar um encerramento OOM, após uma condição anómala relacionada com a localização. Este caso não define a utilização normal de RAM do Immich; demonstra por que razão um crescimento inexplicado deve ser tratado primeiro como uma questão de software ou configuração, antes de aumentar permanentemente o orçamento do anfitrião.

Depois de alterar uma variável de concorrência, modelo ou versão, execute novamente a mesma carga de trabalho. Mantenha a alteração apenas se tanto o padrão de memória como a tarefa original melhorarem na direção esperada. Se a memória continuar a aumentar sem se aproximar de um patamar estável, preserve os registos e os detalhes da versão e proceda a uma análise mais aprofundada, em vez de transformar o limite rígido num número cada vez maior.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Valide o Limite Depois de um Reinício a Frio e de um Ciclo de Utilização Intensa

Reinicie o anfitrião para que as caches e a presença dos modelos na memória comecem num estado frio conhecido. Execute as verificações normais de início de sessão e navegação e, em seguida, o carregamento representativo e a carga de trabalho em segundo plano. Registe o pico de memória anónima, a cache, a swap, os contadores OOM, a resposta da base de dados, o tempo necessário para esvaziar a fila e se outro contentor importante continua responsivo.

Um limite aprovado suporta tanto o arranque a frio como o ciclo normal mais intenso sem encerramentos OOM, thrashing sustentado da swap, reinícios repetidos do contentor ou uma fila que deixe de ser processada. Deve também deixar margem suficiente no anfitrião para tarefas de recuperação, como uma cópia de segurança da base de dados ou um início de sessão administrativo, quando o Immich está ocupado.

Se apenas um teste de esforço artificial falhar, enquanto todas as cargas de trabalho domésticas definidas forem concluídas, documente o limite aceite em vez de comprar RAM para um cenário de que não necessita.

Se uma carga de trabalho real não conseguir ser concluída sem esgotar o anfitrião, reduza a concorrência, isole a aprendizagem automática, adicione memória ou transfira os serviços concorrentes; depois repita a mesma validação antes de declarar seguro o novo limite.