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.
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

Os modelos abertos estão a alcançar a IA de fronteira — será 2026 o ano em que a IA local se torna suficientemente boa?
Os modelos abertos estão a tornar-se suficientemente bons para mais cargas de trabalho locais de IA, enquanto os modelos de ponta na nuvem continuam...

O NVIDIA PAIR transforma a sua rede doméstica num cluster de IA local — ainda precisa de um único servidor com uma GPU potente?
O NVIDIA PAIR distribui pedidos de IA locais por vários PCs, tornando a capacidade de computação mais elástica, enquanto um servidor doméstico pode manter...

Porque é que o Immich parece mais rápido na LAN do que em ligações remotas?
Os pedidos na LAN seguem normalmente um percurso mais curto e com menor latência. O acesso remoto acrescenta limitações de capacidade da WAN e...

