Porque é que o Immich volta a processar os dados existentes depois de uma atualização?

O Immich pode voltar a processar recursos existentes quando uma atualização altera o código, os modelos, os metadados ou as regras de derivados que definem um resultado atual.

As fotografias originais não foram alteradas, mas as miniaturas, incorporações, rostos, pré-visualizações ou registos da base de dados podem já não cumprir os requisitos da nova versão. Segue-se uma explicação delimitada sobre qual resultado foi invalidado, qual fila o regenera e se o trabalho é concluído uma vez ou se se repete anormalmente.

Uma atualização pode alterar o que é considerado um resultado atual

Os dados gerados são válidos relativamente ao código, modelo, definições e esquema que os produziram. Quando essas expectativas mudam, uma miniatura, incorporação, resultado facial ou registo de metadados existente pode deixar de ser considerado atual. O recurso continua a ser a entrada, embora apenas a sua representação derivada precise de ser processada.

O artigo sobre cópias de segurança do Immich da ZimaSpace distingue os originais essenciais e o estado da base de dados dos derivados que podem ser regenerados. Esta distinção explica por que motivo o trabalho de atualização pode ser significativo sem implicar que os ficheiros originais tenham sido duplicados: a aplicação pode estar a reconstruir o estado derivado em torno de ficheiros multimédia inalterados.

Registe quais as filas que crescem imediatamente após a atualização e quais os diretórios ou tamanhos da base de dados que mudam. Uma fila de miniaturas, uma fila de aprendizagem automática e uma migração da base de dados representam mecanismos diferentes. Chamar a todos “reindexação” elimina as provas necessárias para estimar a duração e a pressão sobre os recursos.

Alterações nas dependências e nos modelos podem invalidar trabalho anterior

O Immich abrange o código da aplicação, o comportamento da base de dados, a coordenação das filas, os modelos de aprendizagem automática e os derivados multimédia. Uma atualização pode alterar as interfaces ou as expectativas relativas à representação armazenada entre esses componentes. Uma migração pode atualizar rapidamente os registos, enquanto os trabalhadores em segundo plano regeneram posteriormente resultados dispendiosos para cada recurso afetado.

Uma discussão da comunidade sobre a preparação para o Immich v3 destaca a incerteza em torno do PostgreSQL, do Redis, das extensões vetoriais e das versões da aplicação. A discussão não prova qualquer ação de atualização específica, mas demonstra que a compatibilidade das dependências faz parte da transição de estado, não sendo um simples detalhe de manutenção sem relação.

Preserve as versões dos componentes antes da atualização e um instantâneo das filas depois da atualização. Se apenas uma classe de resultados for agendada e concluída uma vez, o comportamento corresponde a uma regeneração delimitada. Se os componentes não coincidirem quanto ao esquema ou às extensões, podem surgir falhas repetidas antes de o reprocessamento útil sequer começar.

O reprocessamento transforma o trabalho de compatibilidade em pressão sobre os recursos

Uma biblioteca de grande dimensão pode transformar uma regra alterada em milhares de tarefas. A geração de miniaturas e a análise multimédia consomem CPU ou aceleradores, enquanto a leitura dos originais e a escrita dos derivados consomem largura de banda de armazenamento. As atualizações da base de dados e a atividade das filas continuam em simultâneo, pelo que a navegação em primeiro plano pode ficar mais lenta mesmo quando o reprocessamento está a decorrer normalmente.

Um tópico de suporte do Immich relata carga elevada da CPU durante a noite e uma nova geração de miniaturas após uma atualização em dois servidores. Trata-se de um relato de utilização, não de uma prova do comportamento pretendido, mas fornece o padrão de observação exato que deve ser comparado com o progresso das filas, os registos e a recorrência da conclusão.

Acompanhe os itens concluídos por minuto, o espaço livre de armazenamento, a latência dos dispositivos, a pressão da memória e um pedido interativo fixo. Um reprocessamento saudável deve reduzir uma fila finita. Reduzir a simultaneidade pode proteger a utilização doméstica, à custa de uma maior duração; adicionar trabalhadores pode agravar a contenção do armazenamento ou da base de dados quando essas fases já definem o limite.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Distinguir a regeneração única de uma falha repetitiva

Antes da atualização, guarde as contagens das tarefas, as versões, o espaço livre e os identificadores de vários recursos conhecidos. Depois, verifique os mesmos identificadores e registe qual o resultado que é reconstruído, se as contagens das filas diminuem e se o trabalho regressa após um reinício ou durante a janela de manutenção agendada seguinte.

Uma discussão sobre a recuperação de miniaturas relata que as imagens em falta ficaram disponíveis depois de o processamento terminar, enquanto a atualização manual ajudou alguns recursos individuais. Os relatos mistos reforçam a distinção: só o tempo decorrido não permite classificar o comportamento; o progresso de uma fila finita é diferente de os mesmos recursos falharem repetidamente ou voltarem a ser colocados na fila.

Considere que se trata de uma regeneração única quando as filas diminuem continuamente e os resultados permanecem estáveis. Proceda a uma análise mais aprofundada quando as contagens concluídas são repostas, os mesmos recursos reaparecem, os erros se repetem, o espaço livre diminui drasticamente ou não há qualquer débito útil. Preserve as cópias de segurança e os registos antes de alterar o estado das tarefas, pois eliminar provas pode ocultar se foi a atualização ou o ambiente que desencadeou o ciclo.