Determine what limita o Immich reproduzindo uma carga de trabalho fixa de carregamento, navegação, pesquisa ou tarefa em segundo plano, e relacionando a respetiva taxa de conclusão com a saturação do CPU, a pressão da memória, a latência do armazenamento e o débito da rede durante o mesmo intervalo.
Uma percentagem elevada, por si só, não é um estrangulamento: o CPU a 100% pode ser normal durante a aprendizagem automática, uma utilização elevada da RAM pode corresponder à cache do sistema de ficheiros e um carregamento lento pode dever-se ao telemóvel ou à rede Wi-Fi. Meça desde o cliente até ao contentor e ao anfitrião, registe o progresso da fila e, em seguida, altere uma única limitação suspeita e repita o teste. O recurso cujo alívio melhora a mesma carga de trabalho é a limitação determinante.
Crie um teste e uma linha temporal repetíveis
Escolha o sintoma que precisa de melhorar: ingerir um lote fixo de ficheiros multimédia, abrir originais que não estejam em cache, gerar miniaturas, executar a Pesquisa Inteligente ou transcodificar um vídeo. Registe o início, o primeiro resultado utilizável, a conclusão, as falhas e a evolução da fila de tarefas. Misturar tarefas produz gráficos de recursos sem permitir tomar uma decisão.
Uma investigação de um utilizador descreve uma implementação do Immich invulgarmente lenta, procurando evidências relativas ao CPU, à memória, ao disco e à rede. O seu enquadramento de diagnóstico entre recursos é útil, mas o seu teste fixo tem de determinar a causa no seu servidor.
Repita uma vez depois de as caches estarem aquecidas. Se a segunda execução for muito mais rápida, registe o estado da cache em vez de considerar o hardware inconsistente. Se ambas as execuções bloquearem na mesma fase, alinhe esse instante com as métricas do anfitrião e do contentor e com a tarefa responsável.
Identifique os sinais do CPU e da memória
Uma limitação do CPU manifesta-se através de trabalho executável sustentado nos núcleos relevantes, enquanto a tarefa avança proporcionalmente; reduzir a simultaneidade pode melhorar a interação, mas prolonga o tempo necessário para esvaziar a fila. Se um único thread estiver saturado enquanto a utilização total do CPU parecer moderada, consulte a vista por processo e por núcleo antes de presumir que existe capacidade disponível.
Uma limitação da memória exige evidências de pressão: aumento da utilização de swap, recuperação de memória, falhas de página maiores, encerramentos por falta de memória ou reinícios de contentores. Uma utilização elevada da memória, com cache estável, sem swap e com latência normal, não confirma a limitação. Repita o teste com um trabalhador de menor simultaneidade ou com um modelo mais pequeno e compare a conclusão.
Um caso relatado de miniaturas no Immich v2.5.5 consumiu uma quantidade extrema de memória numa implementação. O relato de memória limitado a uma versão justifica verificar a tarefa em falha e a versão instalada; não estabelece um requisito normal de RAM.
Separe a latência do armazenamento do débito da rede
Para o armazenamento, observe a latência do dispositivo, a profundidade da fila, o débito, o espaço disponível no sistema de ficheiros e a disponibilidade de inodes enquanto a tarefa exata estiver a ser executada. Um débito baixo em megabytes por segundo pode ainda indicar uma limitação do armazenamento quando muitas operações pequenas da base de dados e das miniaturas aguardam por um disco de elevada latência.
Para a rede, meça tanto no cliente como no servidor e compare os percursos locais e remotos. Uma ligação saturada, retransmissões, repetições do Wi-Fi ou o limite de uma VPN que coincidam com a transferência indicam uma limitação da rede. Se o tráfego de carregamento terminar, mas o processamento continuar lento, acompanhe a fila no lado do servidor.
A visão geral do ZimaSpace sobre serviços para hardware mais antigo fornece contexto para o planeamento do sistema; este diagnóstico deve continuar a basear-se na latência observada e na taxa de trabalho, e não em classificações relativas à idade.
Alivie uma limitação e verifique a mesma carga de trabalho
Altere uma única variável segura: reduza a simultaneidade de uma tarefa, adicione um teste temporário com limite de memória, mova uma cópia dos dados ativos para um armazenamento mais rápido ou teste através de uma rede local com fios. Mantenha comparáveis o conjunto de dados, as versões e o estado da cache. Uma melhoria tanto na conclusão como na métrica prevista confirma o teste causal.
Não compre hardware com base numa média de inatividade ou num único pico. Vale a pena atualizar um recurso quando este controla repetidamente a carga de trabalho importante, depois de excluir erros de software, problemas de espaço livre e trabalho agendado concorrente.
Reverta as alterações que transfiram a falha para outra camada ou prolonguem as filas para além do objetivo do serviço. Se o sistema bloquear sem que nenhum recurso apresente pressão, forneça a definição da carga de trabalho, os instantes, as métricas por contentor, a latência do disco, os testes de rede, o progresso da fila e os registos ao pedir assistência; esse padrão pode indicar um bloqueio, uma dependência ou uma falha da aplicação.
Suporte e Dicas
Mais para Ler

Como otimizar as ligações à base de dados do Immich para contentores simultâneos
Não aumente primeiro o valor de max_connections. Meça as sessões do Immich, some a procura total de cada contentor, preserve margem para o administrador...

Como evitar trabalhos ou importações duplicados no Immich
Separe os trabalhos repetidos dos recursos duplicados. Utilize um único caminho de ingestão canónico, controle as novas tentativas e as alterações de caminho e,...

Como reparar o Immich depois de o volume da base de dados ficar cheio
Nunca elimine o WAL do PostgreSQL para libertar espaço. Pare as escritas do Immich, preserve o estado da base de dados, adicione capacidade de...

