Como é que o Immich agenda a indexação de pesquisa durante grandes importações de bibliotecas móveis

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

Durante uma grande importação de uma biblioteca móvel, o Immich pode aceitar recursos mais rapidamente do que todos os trabalhos em segundo plano relacionados com a pesquisa conseguem terminar, pelo que a atualização da pesquisa pode ficar atrasada relativamente à conclusão do carregamento.

Esse atraso é apenas um problema de agendamento quando os trabalhos necessários estão à espera, em execução ou em competição por recursos partilhados; não é automaticamente uma falha da pesquisa. O modelo útil é um pipeline: os recursos recebidos geram trabalho, as filas absorvem os picos, os trabalhadores consomem essas filas e a base de dados recebe os resultados dos quais dependem as pesquisas posteriores.

As grandes importações criam um pico de trabalhos diferentes

Uma migração móvel faz mais do que copiar bytes. Cada recurso aceite pode gerar trabalho adicional para miniaturas, metadados, processamento de vídeo, pesquisa inteligente, rostos ou outras funcionalidades ativadas. Como estes trabalhos têm custos e dependências diferentes, uma única importação pode criar vários atrasos com ritmos de escoamento distintos.

O pedido de trabalhos sequenciais mostra por que motivo os utilizadores notam este comportamento em hosts limitados: por vezes, os operadores querem que as atividades pesadas sejam executadas uma de cada vez, em vez de se sobreporem. Esse pedido é indício de competição por recursos, não prova de que a execução sequencial seja a melhor opção para todos os servidores.

Meça cada fila pelos trabalhos que chegam, pelos que terminam e pelas falhas, em vez de tratar o total pendente como uma única carga de trabalho. Uma grande fila de miniaturas pode atrasar o trabalho dependente de forma diferente de uma fila de transcodificação de vídeo, e uma fila que está a diminuir continuamente tem um significado diferente de uma que tenta repetidamente processar os mesmos itens.

A prioridade das filas não é o mesmo que o controlo global dos recursos

Um sistema pode dar prioridade a determinados trabalhos ou colocá-los em pausa e, ainda assim, manter outros tipos de trabalhos ativos. É por isso que uma ferramenta de importação que reduz uma classe de atividade em segundo plano não garante necessariamente um processador inativo, discos silenciosos ou uma atualização imediata da pesquisa. A política de agendamento e o consumo total de recursos estão relacionados, mas não são idênticos.

Uma versão do immich-go introduziu trabalhos em segundo plano pausados durante os carregamentos, para reduzir conflitos. Esse comportamento pertence a esse importador e a essa versão, pelo que não deve ser generalizado como uma afirmação de que todas as importações móveis do Immich pausam automaticamente o mesmo trabalho.

O limite prático é o progresso observável. Se os carregamentos continuarem rápidos enquanto as filas relacionadas com a pesquisa estiverem intencionalmente pausadas, é natural que os novos recursos só fiquem pesquisáveis mais tarde. Se a fila estiver ativada, mas as conclusões permanecerem próximas de zero, a questão passa da política de agendamento para uma falha do trabalhador, dos recursos ou específica dos recursos.

A simultaneidade pode aumentar o débito e piorar a capacidade de resposta

Mais trabalhadores simultâneos podem aumentar o número de trabalhos concluídos por minuto até que uma dependência partilhada fique saturada. A partir desse ponto, o paralelismo adicional pode aumentar a espera na base de dados, a latência do armazenamento, a pressão sobre a memória ou as mudanças de contexto, fazendo com que o sistema termine o trabalho em segundo plano mais rapidamente em média, enquanto os pedidos interativos desenvolvem uma latência de cauda mais longa.

Um relato de um profissional sobre filas de trabalhos bloqueadas descreve uma biblioteca grande em que a redução da simultaneidade melhorou o progresso observado. É uma observação específica dessa implementação, mas demonstra por que motivo a simultaneidade deve ser testada como uma variável da carga de trabalho, em vez de ser tratada como um indicador fixo da capacidade do servidor.

Use como controlo interativo uma pesquisa conhecida de um álbum já indexado. Se essa consulta continuar rápida enquanto a cobertura das fotografias novas fica atrasada, a importação é principalmente um problema de atualização. Se até as consultas antigas ficarem mais lentas ao mesmo tempo que aumentam a utilização do processador, a espera do armazenamento ou da base de dados, a janela de agendamento está a consumir a margem disponível para a utilização interativa.

-15% OFF

Uma fila em crescimento não é automaticamente uma falha

O atraso cresce sempre que o trabalho chega mais depressa do que os trabalhadores o conseguem concluir. Durante uma importação histórica intencional, isso é esperado durante algum tempo. O sinal de falha não é o pico da fila em si, mas a combinação de conclusões interrompidas, erros repetidos ou uma fila que não consegue diminuir depois de os novos trabalhos deixarem de chegar.

Discussões sobre grandes importações, como esta sobre uma migração de 200 000 fotografias, mostram como os operadores distinguem o débito do carregamento do processamento posterior. A experiência da comunidade é útil para identificar o que medir, mas não deve ser convertida numa estimativa universal de tempo para outra biblioteca.

Este mecanismo deixa de explicar resultados de pesquisa em falta quando o trabalho relevante foi concluído e o mesmo utilizador autorizado continua sem conseguir obter um recurso conhecido. Nesse momento, analise a relevância da consulta, os filtros, as permissões, o comportamento do modelo ou o processamento específico do recurso, em vez de continuar a ajustar a simultaneidade da importação.

Execute um teste de agendamento com duas vias

Crie uma via fixa para conteúdo antigo já indexado e outra para uma pequena importação nova. Antes da importação, registe o tempo de resposta de uma pesquisa conhecida de conteúdo antigo. Durante a importação, registe essa mesma pesquisa, a taxa de carregamento, o número de trabalhos pendentes e concluídos, as falhas, a pressão sobre o processador e a memória e a latência do armazenamento em intervalos regulares.

Use a análise da ZimaSpace sobre o percurso de dados do Immich para manter distintas as fases de transferência, processamento, armazenamento e pesquisa. Um estrangulamento só é acionável quando coincide com a fase cujo objetivo de serviço está efetivamente a ser incumprido.

Aceite o agendamento quando as pesquisas antigas se mantiverem dentro do limite de tolerância da sua casa, as filas de novos itens continuarem a ser processadas e o atraso diminuir depois de os novos trabalhos deixarem de chegar. Reduza ou reagende a simultaneidade do trabalho em segundo plano apenas quando o teste controlado demonstrar que o mesmo recurso partilhado está a atrasar tanto a utilização interativa como o progresso da fila.

Centro de Tecnologia e IA

Mais para Ler

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.