O que faz com que a pesquisa ou os resultados das consultas do Immich fiquem mais lentos à medida que os dados aumentam?

A pesquisa no Immich fica mais lenta à medida que cresce quando os índices maiores e os conjuntos de trabalho excedem a capacidade eficiente da cache, da filtragem ou do armazenamento — não simplesmente porque existem fotografias.

Uma biblioteca maior aumenta várias quantidades em simultâneo: linhas, embeddings, metadados, miniaturas e possíveis combinações de filtros. Diagnostique a fase que abranda, porque um armazenamento de ficheiros mais rápido não corrige um percurso de consulta deficiente, enquanto o ajuste da base de dados não consegue acelerar uma montagem remota de miniaturas.

O crescimento expande mais do que a biblioteca original

Cada recurso adicionado pode contribuir com linhas na base de dados, metadados extraídos, representações para pesquisa, rostos, miniaturas e conteúdos multimédia codificados. Estas estruturas crescem a ritmos diferentes e são acedidas de formas distintas. Por isso, os terabytes da biblioteca original não permitem prever a latência da pesquisa sem saber quantas entidades pesquisáveis e objetos derivados o pedido percorre.

A análise do percurso de dados do Immich da ZimaSpace separa o processamento em segundo plano, as representações pesquisáveis, a seleção na base de dados e os conteúdos multimédia entregues. A lição prática para diagnosticar consultas é que o crescimento da biblioteca altera tanto o catálogo pesquisável como os ficheiros apresentados após um resultado, criando mais do que um possível atraso.

Registe a quantidade de recursos, o tamanho da base de dados, o tamanho do índice vetorial, o espaço ocupado pelas miniaturas e a cardinalidade dos filtros usados com frequência em cada marco. Uma série temporal revela qual estrutura cresce em simultâneo com a latência e evita atribuir o tempo de seleção na base de dados a um aumento não relacionado dos bytes de vídeos originais.

Os índices vetoriais tornam-se sensíveis ao ajuste à memória

A pesquisa semântica percorre um índice de representações em vez de ler todas as imagens originais. À medida que esse índice cresce, o respetivo grafo ou as respetivas páginas ativas podem deixar de permanecer na memória. As falhas aleatórias de cache transformam então operações à velocidade da memória em leituras do armazenamento, fazendo subir a latência de cauda mais acentuadamente do que sugere a utilização média da CPU.

Uma análise de engenharia da pesquisa vetorial no PostgreSQL explica que o desempenho do HNSW pode degradar-se quando o grafo ativo excede a memória, porque a travessia de acesso aleatório se torna sensível às falhas de cache. As versões do Immich e as implementações dos índices podem mudar, por isso use isto como um mecanismo a testar e não como uma prescrição de configuração.

Meça uma consulta semântica fixa após reiniciar, depois de um aquecimento e após aceder a regiões não relacionadas da biblioteca. Compare as leituras da base de dados, o comportamento dos acertos da cache e a latência do dispositivo. Ganhos significativos após o aquecimento que desaparecem à medida que o conjunto de trabalho se alarga sustentam a hipótese de ajuste à memória; consultas uniformemente lentas apontam para outro problema.

Os filtros e os planos de consulta podem mudar com a cardinalidade

A data, a pessoa, o proprietário, o álbum e outras condições alteram o número de candidatos que permanecem antes ou durante a classificação. À medida que a distribuição dos dados muda, o mesmo filtro visível pode selecionar uma fração muito maior da biblioteca. As estatísticas da base de dados e as escolhas do plano podem, por isso, ser importantes mesmo quando o termo de pesquisa permanece inalterado.

Uma análise das limitações do pgvector observa que combinar a pesquisa vetorial com filtros de metadados pode ser difícil e que as cargas de trabalho vetoriais partilham CPU, memória e E/S do PostgreSQL com operações transacionais. O artigo apresenta evidência geral sobre o PostgreSQL, pelo que sustenta o mecanismo, mas não comprova um plano de consulta específico do Immich.

Crie pesquisas emparelhadas com e sem um filtro, utilizando conjuntos de resultados conhecidos. Registe o tempo da consulta no servidor e a atividade da base de dados, não apenas a conclusão no navegador. Se o tempo de seleção aumentar enquanto as miniaturas devolvidas continuarem rápidas, concentre-se nos planos, nas estatísticas, no ajuste do índice e na contenção, em vez do armazenamento multimédia.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Separe a seleção dos resultados da apresentação dos resultados

A interface pode parecer lenta depois de a base de dados já ter selecionado os identificadores dos recursos correspondentes. A apresentação ainda requer a procura das miniaturas, leituras do armazenamento, transferência da resposta e descodificação no cliente. Uma árvore de derivados em crescimento ou uma montagem remota pode atrasar esta segunda fase, enquanto a consulta de pesquisa propriamente dita continua saudável.

Um relato de uma importação de grande dimensão descreve uma lentidão generalizada no Immich enquanto permaneciam em fila centenas de milhares de tarefas de metadados e miniaturas. Demonstra uma pressão sobreposta em segundo plano, não um limite universal de escala, e mostra por que razão os testes de crescimento devem ser executados tanto com as filas ativas como depois de estas esvaziarem.

Utilize a temporização do navegador ou observações da API para assinalar separadamente a conclusão da resposta dos resultados e a última miniatura visível. Repita uma pesquisa conhecida com as filas pausadas e, depois, ativas. Se os identificadores ficarem mais lentos, investigue os percursos da base de dados e do índice; se apenas as imagens ficarem mais lentas, examine o armazenamento das miniaturas, a entrega pela rede, a descodificação no cliente e a E/S em segundo plano concorrente.