Se o icewhale-files-backup crescer para vários gigabytes de RAM e acionar repetidamente o OOM killer no ZimaOS 1.7.0, atualize primeiro para o ZimaOS 1.7.1 ou posterior. As notas de lançamento da IceWhale para a versão 1.7.1 corrigem explicitamente o uso anormal de memória em determinados cenários de operações com ficheiros, bem como falhas e interrupções de cópias de segurança.
O tópico de origem documentou uma regressão grave na versão 1.7.0: a memória aumentava de cerca de 3,5 GB para mais de 10 GB, o kernel terminava o Backup, Restart=always fazia-o regressar e o ciclo desestabilizava o servidor. Mascarar o serviço interrompia o ciclo, mas era apenas uma solução de emergência.
Reconhecer o ciclo de OOM
journalctl -k | grep -i -E 'oom|out of memory|killed process'
ps aux --sort=-%mem | head
free -hSe o processo Backup voltar repetidamente a ser o maior consumidor de memória, o ciclo de reinício pode deixar o Docker e outros serviços sem recursos.
Atualizar para a versão 1.7.1 ou posterior
As notas de lançamento oficiais do ZimaOS 1.7.1 incluem correções para o uso anormal de memória e para tarefas de cópia de segurança que podiam falhar ou ser interrompidas.
Recuperação de emergência no ZimaOS 1.7.0
sudo systemctl stop icewhale-files-backup.service
sudo systemctl disable icewhale-files-backup.service
sudo systemctl mask icewhale-files-backup.serviceMascarar o serviço era necessário porque pará-lo ou desativá-lo normalmente nem sempre impedia o seu relançamento devido à política de reinício do serviço.
Compreender o que o mascaramento desativa
O mascaramento desativa a funcionalidade integrada de Backup. Utilize-o apenas para estabilizar um anfitrião inutilizável durante o tempo necessário para atualizar o sistema ou recuperar os dados.
Remover o mascaramento após a atualização
sudo systemctl unmask icewhale-files-backup.service
sudo systemctl enable icewhale-files-backup.service
sudo systemctl start icewhale-files-backup.serviceEm seguida, execute uma cópia de segurança pequena e controlada, monitorizando a RAM e a memória swap.
As cargas de trabalho de cópia para USB eram um fator desencadeante comum
Vários utilizadores relataram um comportamento semelhante com destinos de cópia de segurança USB. Isto ajuda a reproduzir o erro, mas não prova que a caixa externa tenha sido a sua causa.
Verificar a integridade da cópia de segurança
Compare o número de ficheiros na origem e no destino e efetue um teste de restauro. O guia de verificação de cópias de segurança ajuda a reduzir a dependência de uma única tarefa.
Verificar se o Docker foi afetado pela falta de memória
No tópico, a pressão prolongada sobre a memória acabou por tornar as aplicações Docker indisponíveis. Depois de o anfitrião estar estável, verifique docker ps, o daemon do Docker e os contentores críticos antes de reiniciar uma carga de trabalho de cópia de segurança de grandes dimensões.
Começar com uma cópia de segurança pequena após a atualização
Não volte a executar imediatamente a tarefa de vários terabytes ou a tarefa USB que desencadeou a falha. Crie uma tarefa de teste pequena, monitorize a memória durante 10–20 minutos e aumente gradualmente o número de ficheiros e o tamanho total. Isto facilita verificar se o serviço corrigido mantém o consumo de memória limitado.
O número de ficheiros é tão importante como o número de bytes
Centenas de milhares de ficheiros pequenos podem gerar muito mais trabalho de metadados do que alguns ficheiros multimédia grandes. Ao apresentar um relatório ao suporte, inclua tanto o total de bytes como o número aproximado de ficheiros.
Manter um caminho de cópia de segurança independente durante os testes
Se a funcionalidade integrada de Backup tiver ficado incompleta ou instável anteriormente, mantenha outra cópia comprovadamente válida, utilizando uma ferramenta ou um destino separado, até que um teste de restauro confirme a fiabilidade da tarefa atual do ZimaOS.
Guardar os registos anteriores e posteriores à correção
Guarde as mensagens de OOM, os processos que mais memória consumiam, a versão do ZimaOS e o tipo de destino da cópia de segurança antes da atualização. Em seguida, repita a mesma carga de trabalho controlada após a versão 1.7.1 ou posterior e compare o crescimento da memória. Isto fornece provas de que a regressão foi resolvida, em vez de depender apenas de o servidor “parecer estável”.
Se a memória continuar a crescer sem limite na versão corrigida, interrompa a tarefa e envie essas medições anteriores e posteriores ao suporte.
Perguntas frequentes
A fuga de memória foi confirmada por vários utilizadores?
Sim. Vários utilizadores relataram o mesmo comportamento na versão 1.7.0.
A versão 1.7.1 resolveu este tipo de problema?
Sim. O registo oficial de alterações inclui correções de memória e de cópias de segurança que correspondem diretamente a este problema.
Devo reverter para a versão 1.6.2?
Essa foi uma solução temporária anterior à versão 1.7.1. Os utilizadores atuais devem preferir a versão estável corrigida.
Como sei se a correção funcionou?
Execute uma cópia de segurança controlada, monitorizando a memória, a swap, os registos e a integridade do destino.
