Porque é que o Immich provoca atividade repetida do disco durante a noite?

O Immich pode gerar atividade repetida no disco durante a noite porque a manutenção agendada, as operações da base de dados, as tarefas multimédia em fila ou as tentativas repetidas continuam depois de as pessoas deixarem de utilizar a biblioteca.

Uma casa silenciosa não significa que o servidor esteja inativo. A questão útil é saber se o mesmo processo e a mesma tarefa explicam as leituras ou escritas à mesma hora. Correlacione primeiro a atividade e só depois decida se se trata de trabalho esperado, recuperação de um atraso acumulado ou um ciclo que deve ser interrompido.

Associe o pico do disco à hora antes de alterar qualquer coisa

Comece por três noites de registos temporais, em vez de uma única observação ruidosa. Registe quando aumenta a E/S de blocos, qual o dispositivo ocupado, se predominam as leituras ou as escritas e se o padrão começa praticamente à mesma hora. Uma hora de início repetível aponta para um agendador; um padrão irregular aponta mais para chegadas, tentativas repetidas ou outro contentor.

As implementações do Immich podem agendar cópias de segurança da base de dados e tarefas de integridade durante as horas de menor utilização, pelo que um pico de madrugada pode ser intencional. Não desative uma tarefa apenas porque esta ativa os discos. Verifique primeiro se surge uma cópia de segurança correspondente, um resultado de manutenção ou a conclusão de uma fila após o período de atividade.

O diagnóstico adjacente da ZimaSpace sobre o trabalho em segundo plano do Immich durante as horas de inatividade utiliza a mesma regra temporal: associe o sintoma visível ao processo e à tarefa antes de considerar a “inatividade” um estado de falha.

Separe as escritas do PostgreSQL das leituras multimédia

As alterações ao estado da aplicação Immich podem manter o PostgreSQL ativo mesmo quando nenhuma fotografia nova está a ser aberta. Os pontos de verificação da base de dados, o registo de escrita antecipada, as tarefas relacionadas com o vacuum e as atualizações normais da aplicação têm uma assinatura de E/S diferente da análise de milhares de ficheiros multimédia. Identifique o caminho ou dispositivo que recebe o tráfego antes de culpar a biblioteca de fotografias.

A discussão sobre observabilidade do PostgreSQL em análise de pg_stat_io explica por que motivo as leituras, as escritas, a atividade do backend, o comportamento do verificador de pontos de controlo e as escritas em segundo plano devem ser separados. Utilize essa distinção para determinar se o dispositivo da base de dados está ocupado porque transações úteis estão a ser persistidas ou porque algo está a gerar atividade repetitiva.

Se as escritas da base de dados forem pequenas e periódicas enquanto os discos multimédia permanecem inativos, o comportamento pode corresponder a tarefas normais de manutenção da base de dados. Se o mesmo ficheiro da base de dados receber escritas intensas e contínuas sem que nenhuma tarefa avance, preserve os registos e analise as consultas responsáveis ou o ciclo de reinício, em vez de transferir toda a biblioteca para um armazenamento mais rápido.

Verifique se as filas em segundo plano estão realmente a avançar

Abra a vista de tarefas e compare o trabalho pendente, ativo, falhado e concluído antes e depois do período noturno. A geração de miniaturas, o processamento de vídeos, a extração de metadados, as tarefas de aprendizagem automática ou o trabalho sobre uma biblioteca importada podem legitimamente manter o armazenamento ativo depois de uma grande alteração. Uma fila em diminuição é indício de recuperação útil de trabalho acumulado.

Um relatório atual da comunidade sobre leituras contínuas sem explicação mostra o limite diagnóstico oposto: leituras contínuas muito elevadas, sem trabalho esperado, merecem investigação, em vez de serem normalizadas como “aquilo que o Immich faz”. Considere a taxa comunicada como um caso, não como uma referência.

Se as mesmas tarefas falharem e voltarem a entrar na fila, a atividade do disco pode repetir-se sem produzir progresso. Registe o primeiro erro e um recurso afetado e, em seguida, isole esse tipo de tarefa. Não limpe todas as filas nem volte a gerar a biblioteca inteira antes de determinar se o ciclo é causado por um ficheiro, permissões, latência do armazenamento ou uma dependência do serviço.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Atribua a E/S a um processo em vez de adivinhar pelo ruído da unidade

Utilize a monitorização de E/S ao nível do anfitrião durante a próxima recorrência para identificar o processo que está a ler ou escrever no dispositivo. Depois, associe esse processo ao servidor Immich, ao PostgreSQL, à aprendizagem automática, a uma ferramenta de cópia de segurança, a um antivírus, a uma verificação do sistema de ficheiros ou a outro contentor não relacionado. Os LED das unidades e o ruído das ventoinhas não fornecem essa informação de propriedade.

Um fluxo de trabalho prático com o iotop demonstra o método centrado no processo. Registe várias amostras, porque um pico curto pode desaparecer entre observações; o objetivo é apanhar o processo durante o mesmo período em que o sintoma ocorre.

Se o Immich não for o principal responsável pela E/S, pare de alterar as definições do Immich e siga o processo real. Se o responsável for o PostgreSQL, o Immich ou um trabalhador relacionado, correlacione os respetivos registos e o progresso das tarefas com a amostra de E/S. Isso transforma “o servidor faz ruído todas as noites” num componente e num acionador específicos.

Defina o limite entre o trabalho noturno normal e uma falha

Considere a atividade normal quando esta começa perto de um agendamento conhecido ou de uma alteração recente da biblioteca, conclui trabalho útil, não deixa a contagem de falhas aumentar e faz regressar a latência do armazenamento e a profundidade da fila aos valores de referência. Registe a duração normal para que um aumento futuro tenha um ponto de comparação.

Uma discussão histórica do Immich sobre escritas frequentes na base de dados ilustra por que motivo pode existir alguma atividade da base de dados sem uma ação visível do utilizador. Como as versões e as implementações mudam, utilize o caso apenas para justificar a medição separada da base de dados, não para declarar normal qualquer escrita persistente.

Aumente o nível de investigação quando a E/S continuar depois de as filas pararem, os mesmos erros se repetirem, a latência do armazenamento afetar a utilização durante o dia, o espaço livre diminuir inesperadamente ou o padrão aumentar noite após noite. Preserve os registos temporais, a E/S dos processos, as contagens de tarefas, os registos relevantes, o espaço livre do sistema de ficheiros e um acionador reproduzível antes de efetuar alterações invasivas.