Se o ZimaOS 1.6.2 entrar num ciclo de reinícios após uma operação de ficheiros de grandes dimensões e icewhale-files ou icewhale-files-backup consumir vários gigabytes de RAM, atualize para o ZimaOS 1.7.1 ou posterior antes de aplicar máscaras permanentes aos serviços. O ZimaOS 1.7.1 corrigiu oficialmente a utilização anormal de memória em determinados cenários de operações de ficheiros.
O relatório de origem continua a ser útil porque documenta claramente a sequência da falha: foram copiados cerca de 749 000 ficheiros, os serviços de ficheiros cresceram para aproximadamente 6 GB no total numa máquina com 7,5 GB de RAM, a swap atingiu quase 100% e o servidor reiniciava a cada 9–10 minutos. A aplicação de máscaras aos serviços interrompeu o ciclo — mas também desativou a aplicação Web Files e o serviço Backup.
Reconhecer o padrão de exaustão de memória
Sinais típicos:
- RAM quase esgotada;
- swap quase cheia;
-
icewhale-filesentre os processos que mais memória consomem; - espera de E/S muito elevada ou bloqueios aparentes do sistema;
- reinícios repetidos semelhantes aos provocados pelo watchdog após operações com um grande número de ficheiros.
Passo 1: Atualizar para o ZimaOS 1.7.1 ou posterior
As notas de versão oficiais do ZimaOS 1.7.1 indicam explicitamente uma correção para a utilização anormal de memória em cenários de operações de ficheiros.
Essa é a principal correção atual. A solução alternativa da versão 1.6.2 não deve ser a sua configuração normal em 2026.
Passo 2: Medir a RAM e a swap
free -h
ps aux --sort=-%mem | head
swapon --showConfirme se os serviços de ficheiros são realmente responsáveis antes de desativar qualquer coisa.
Passo 3: Verificar os reinícios recentes
journalctl --list-bootsUm intervalo repetido pode ajudar a distinguir o comportamento do watchdog/reinício de uma perda de energia aleatória.
Paragem de emergência num sistema 1.6.2 antigo
Se o servidor não conseguir permanecer ligado tempo suficiente para atualizar, o utilizador de origem estabilizou-o com:
sudo systemctl parar icewhale-files.service icewhale-files-backup.service
sudo systemctl mascarar icewhale-files.service icewhale-files-backup.serviceEsta é uma medida de recuperação de emergência. Desativa funcionalidades nativas importantes. Após a atualização, remova as máscaras e teste os serviços atuais normalmente.
Remover a máscara após a recuperação
sudo systemctl remover a máscara de icewhale-files.service icewhale-files-backup.service
sudo systemctl iniciar icewhale-files.service icewhale-files-backup.serviceFaça isto apenas depois de o sistema estar numa versão corrigida/atual e de ter estabilidade suficiente para observar o comportamento da memória.
Um número elevado de ficheiros é diferente de um ficheiro de grandes dimensões
749 000 ficheiros pequenos podem sobrecarregar os metadados/a indexação muito mais do que um vídeo de 67 GB. Ao reproduzir ou comunicar o problema, inclua tanto o total de bytes como o número de ficheiros.
NTFS/FUSE e muitos contentores aumentam a pressão
A máquina de origem também executava cerca de 38 contentores e vários volumes NTFS através de ntfs-3g. Essas condições são contexto, não causas comprovadas. Evite transformá-las na causa principal quando o aumento de memória observado ocorreu nos serviços de ficheiros da IceWhale.
Não adicione um MemoryMax aleatório como primeira solução atual
O autor da fonte sugeriu o systemd MemoryMax= como melhoria do produto. Numa versão atual, limitar artificialmente o serviço pode criar novas falhas de indexação ou de cópia de segurança se a carga de trabalho necessitar legitimamente de memória.
Atualize primeiro e meça depois. Aplique limites aos serviços apenas quando compreender o compromisso envolvido.
Mantenha os AppData fora da pequena unidade do sistema
A exaustão de memória pode criar uma E/S temporária intensa. O atual guia de armazenamento de aplicações do ZimaOS recomenda mover os AppData para o armazenamento principal.
O guia de resolução de problemas de desempenho fornece uma lista de verificação mais abrangente dos recursos.
Perguntas frequentes
O ZimaOS 1.7.1 corrigiu este erro de memória?
Corrigiu oficialmente o consumo anormal de memória em determinados cenários de operações com ficheiros, que coincidem diretamente com o padrão de falha observado.
Devo desativar permanentemente o icewhale-files?
Não. A desativação é uma solução de emergência que desativa as funcionalidades Ficheiros e Cópia de segurança.
Porque é que o swap tornou o servidor pior?
Quando a RAM se esgota, a paginação agressiva pode gerar uma E/S intensa do disco e longas paragens, especialmente quando os serviços de ficheiros já estão a analisar ou a copiar um número enorme de ficheiros.
Que provas devo recolher se isto continuar a acontecer?
Versão do ZimaOS, número de ficheiros, tamanho transferido, estado da RAM/swap, processos que mais memória consomem, tipos de montagem/sistema de ficheiros e registos de data e hora do arranque/reinício.
