Como testar se o Immich está limitado pela CPU, memória, rede ou armazenamento

Teste o Immich com uma operação repetível, correlacione a respetiva latência com as esperas por recursos e confirme o estrangulamento suspeito através de uma intervenção controlada.

Uma captura do painel não consegue distinguir atividade útil de contenção prejudicial. Meça um endpoint — como a aceitação de carregamentos, a apresentação de miniaturas ou a resposta da pesquisa inteligente — sob condições fixas de multimédia e cliente, e altere apenas o recurso suspeito de limitar o desempenho.

Defina um Endpoint e uma Linha de Base Reproduzível

Comece por identificar o endpoint em termos observáveis. “O Immich está lento” não é testável, mas “as mesmas vinte miniaturas da cronologia demoram quatro segundos a aparecer depois de um reinício” é. Fixe o cliente, o caminho de rede, a conta, o conjunto de fotografias e a condição inicial, para que as execuções posteriores difiram apenas numa variável pretendida.

O modelo do caminho de dados do Immich mostra que o carregamento, o processamento, a seleção na base de dados e a entrega de multimédia percorrem dependências diferentes. Um teste destinado à seleção de resultados de pesquisa deve medir a lista de resultados separadamente da apresentação das imagens; caso contrário, uma consulta rápida seguida de leituras de ficheiros lentas é comunicada como um único atraso indiferenciado.

Execute a linha de base pelo menos três vezes e preserve tanto a mediana como o percentil útil mais lento. Registe a profundidade da fila, o CPU por contentor, a pressão da memória, a atividade de swap, o débito de rede e as retransmissões, a latência do disco e a profundidade da fila de E/S. Uma alegação de estrangulamento tem de alinhar o sinal do recurso com o atraso do endpoint.

Separe a Saturação do CPU da Pressão da Memória

Uma execução limitada pelo CPU mantém trabalho pronto à espera de tempo de processador, pelo que a latência do endpoint deve acompanhar uma saturação sustentada dos núcleos ou a limitação térmica. Uma execução limitada pela memória pode, em vez disso, apresentar recuperação de memória, swap, encerramentos de contentores ou carregamentos repetidos de modelos. Ambos os casos podem fazer com que os gráficos do CPU pareçam ocupados, mas as respetivas intervenções produzem respostas diferentes.

Um guia independente de recursos do Immich recente distribui a utilização pelo servidor, PostgreSQL, Redis e componentes de aprendizagem automática, em vez de tratar a RAM total como um único requisito. Esta perspetiva ao nível dos serviços é importante porque pode existir memória livre no anfitrião juntamente com um limite de contentor insuficiente, enquanto uma cache de ficheiros grande não indica automaticamente pressão.

Verifique a pressão do CPU reduzindo a simultaneidade dos trabalhadores em segundo plano ou atribuindo mais CPU, mantendo a memória constante. Verifique a pressão da memória removendo a atividade de swap ou aumentando um limite de memória restritivo, sem alterar o número de trabalhadores. Se o endpoint não melhorar de forma consistente, rejeite esse recurso como o principal limite deste teste.

Distinga o Atraso da Rede do Atraso do Armazenamento

Os limites da rede e do armazenamento aparecem frequentemente em conjunto porque os conteúdos multimédia remotos atravessam ambos. Uma ligação saturada limita o número de bytes transferidos por segundo, enquanto a contenção do armazenamento aumenta o tempo de conclusão das leituras ou escritas, mesmo numa ligação pouco utilizada. Testar apenas a partir de um cliente remoto pode, por isso, atribuir incorretamente a entrega lenta de ficheiros à camada errada.

A análise da Kingston sobre SSDs salienta o trabalho em segundo plano, o comportamento do firmware, a colocação em cache e os comandos do anfitrião que afetam a resposta do armazenamento para além da velocidade sequencial anunciada. No Immich, muitas operações pequenas de miniaturas e bases de dados tornam a latência e o comportamento das filas mais informativos do que um único resultado de largura de banda com ficheiros grandes.

Repita o endpoint a partir de um cliente local ligado por cabo e, depois, através do caminho remoto normal, sem alterar o conjunto de dados do servidor. Leia separadamente um conjunto representativo de ficheiros no anfitrião e observe a latência do dispositivo. Uma melhoria apenas no cliente local implica o caminho de rede; esperas persistentes no anfitrião implicam o armazenamento ou a respetiva montagem.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Utilize uma Matriz de Intervenções para Aceitar ou Rejeitar Cada Causa

Escreva quatro linhas antes de testar: CPU, memória, rede e armazenamento. Dê a cada linha um sintoma esperado, uma intervenção direcionada e uma condição de rejeição. Isto impede que o diagnóstico mude depois de surgirem os resultados e torna uma conclusão negativa útil, em vez de ser um motivo para comprar várias atualizações de uma só vez.

Um relato de campo público sobre o Immich, com miniaturas atrasadas apesar de uma largura de banda de Internet substancial, demonstra por que motivo as especificações, por si só, são insuficientes. A evidência relevante é saber se uma alteração direcionada move o endpoint medido enquanto a coorte de conteúdos multimédia, a condição da cache, as tarefas, o cliente e a versão da aplicação permanecem fixos.

Aceite o CPU apenas se o alívio do processador melhorar a latência; a memória apenas se o alívio da recuperação de memória o fizer; a rede apenas se o alívio do caminho o fizer; e o armazenamento apenas se uma menor espera do dispositivo ou da montagem o fizer. Se duas intervenções ajudarem, repita-as em ambas as ordens, porque o segundo estrangulamento pode tornar-se visível apenas depois de o primeiro ser removido.