Porque é que as tarefas em segundo plano do Immich aumentam subitamente após uma alteração na biblioteca?

O trabalho em segundo plano do Immich pode aumentar significativamente após uma alteração numa biblioteca, porque um único evento do sistema de ficheiros ou da biblioteca pode desencadear tarefas de análise, metadados, derivados e indexação.

A distinção importante é entre uma vaga limitada de reprocessamento esperado e trabalho que revisita repetidamente os mesmos recursos sem uma alteração correspondente. Uma mudança de pasta, uma nova análise de uma biblioteca externa, ficheiros recém-descobertos ou um comportamento específico da versão podem todos produzir gráficos semelhantes de CPU e filas, pelo que o evento da biblioteca deve ser associado às tarefas exatas que criou.

Uma análise da biblioteca é uma fase de descoberta, não toda a carga de trabalho

Uma análise começa por reconciliar o que o Immich consegue ver no disco com o que já conhece da biblioteca. A descoberta de um recurso novo ou alterado pode então tornar desatualizados ou inexistentes os resultados dependentes, criando trabalho adicional depois de a própria análise parecer concluída.

Um relato de utilizador sobre análises sobrepostas de bibliotecas descreve uma fila de análise a ser concluída enquanto as filas de miniaturas, reconhecimento facial e outras permaneciam muito preenchidas. O mecanismo útil é a ramificação: uma fase curta de descoberta pode criar uma cauda de processamento muito mais longa.

Leia as filas pela ordem das dependências. Se a fila da biblioteca chegar a zero enquanto as filas de trabalho derivado continuam a avançar, o servidor pode simplesmente estar a consumir tarefas produzidas pela análise concluída. Chamar a todo o período uma análise repetida obscurece qual é realmente a fase que está a utilizar recursos.

Alterações de caminho podem parecer trabalho de novos recursos

As bibliotecas externas são especialmente sensíveis à identidade do sistema de ficheiros e às alterações de caminho. Quando os ficheiros são reorganizados, a aplicação pode ter de reconciliar as novas localizações com o estado armazenado dos recursos. Dependendo do comportamento da versão e do tipo de biblioteca, isso pode desencadear mais trabalho do que o número de fotografias verdadeiramente novas sugere.

Uma discussão de 2026 sobre ficheiros externos movidos documenta um caso em que os caminhos reorganizados foram tratados como recursos novos, levando à renovação de miniaturas, à análise por ML e ao processamento de vídeos. Trata-se de um relato de limitação conhecida, não de uma garantia de que todas as mudanças de pasta se comportem da mesma forma.

Isto explica por que razão uma reorganização da biblioteca pode ser muito mais dispendiosa do que adicionar o mesmo número de fotografias novas. No entanto, se os caminhos e o conteúdo dos ficheiros não tiverem mudado, a regeneração completa repetida aponta para uma condição diferente e deve ser investigada, em vez de ser aceite como comportamento normal em segundo plano.

As filas dependentes podem crescer enquanto o trabalho é concluído

O número de itens em espera não tem de diminuir de forma monotónica. Quando uma tarefa termina, pode tornar um recurso elegível para outra tarefa ou adicionar mais tarefas a uma fase posterior. Durante uma grande reconciliação, o servidor pode, portanto, apresentar progresso ativo e uma fila dependente crescente ao mesmo tempo.

A discussão sobre um acumular de miniaturas observa que podem surgir novas tarefas de miniaturas à medida que outro processamento é concluído. Também ilustra um limite importante: erros históricos e caminhos de importação mal configurados podem criar ciclos patológicos, pelo que uma fila crescente deve ser interpretada tendo em conta a versão e os caminhos.

Utilize contadores de trabalho concluído e verifique alguns resultados recentes, em vez de observar apenas o número de itens em espera. Se as miniaturas estiverem a aparecer, as conclusões estiverem a aumentar e a taxa acabar por ultrapassar as novas entradas, a fila está a esvaziar-se, mesmo que o seu pico ocorra depois de a análise original da biblioteca ter terminado.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Um pico é anormal quando o trabalho não corresponde a nenhuma alteração

A carga esperada em segundo plano deve poder ser atribuída a um evento definido: recursos novos, uma atualização de metadados, um caminho alterado, uma alteração de modelo ou uma ação explícita de regeneração. A explicação torna-se menos convincente quando os mesmos recursos antigos são agendados repetidamente sem qualquer alteração de configuração ou conteúdo.

Um relato recente em que uma análise afetou outras bibliotecas pareceu regenerar trabalho em várias bibliotecas externas, mostrando por que razão o âmbito é importante. Trate relatos deste tipo como evidência limitada à respetiva versão, para comparação com os seus próprios registos, e não como comportamento normal de base do Immich.

O mecanismo também deixa de explicar um anfitrião que continua ocupado muito depois de as filas relevantes estarem vazias. Nesse caso, verifique a manutenção da base de dados, as cópias de segurança, outro contentor, a atividade do sistema de ficheiros ou um processo bloqueado. Uma alteração da biblioteca não deve tornar-se uma explicação genérica para uma carga sustentada não relacionada.

Associe a alteração a um mapa de tarefas antes e depois

Antes de uma alteração controlada da biblioteca, registe o número de recursos, os números de itens em espera e ativos das principais tarefas, a utilização da CPU, a latência do armazenamento e a hora da última análise concluída. Adicione ou mova um pequeno conjunto conhecido, repita a observação e anote exatamente quais as filas que crescem e a rapidez com que diminuem.

Utilize a explicação da ZimaSpace sobre o percurso de dados do Immich para atribuir cada pico à descoberta, ao processamento, à base de dados ou ao armazenamento, em vez de tratar toda a atividade em segundo plano como uma única categoria.

Aceite o pico quando o trabalho gerado for proporcional à alteração controlada, os resultados aparecerem, as falhas permanecerem limitadas e as filas regressarem gradualmente aos valores normais. Investigue quando recursos inalterados forem regenerados repetidamente, o âmbito exceder a biblioteca editada ou as mesmas tarefas falharem sem progresso.