Corrigir o alto uso de CPU do Zimbra com ClamAV ou FreshClam

Quando um servidor Zimbra repentinamente fica lento, os administradores costumam ver clamdo ClamAV freshclamno topo da lista de processos em execução tope presumem que o serviço antivírus está travado. Isso pode acontecer, mas os dois processos executam tarefas diferentes: freshclamo ClamAV baixa e verifica atualizações de assinaturas, enquanto clamdo ClamAV verifica arquivos e mensagens. Uma fila de e-mails sobrecarregada, uma recarga de banco de dados, um loop de atualização com falha ou um segundo daemon antivírus em execução podem dar a impressão de que o ClamAV está consumindo muita CPU. Identifique qual processo está consumindo muita CPU antes de reiniciar qualquer coisa ou alterar as configurações do antivírus.

Este guia aborda desde verificações de baixo risco até a recuperação do serviço. Os comandos e caminhos abaixo refletem instalações comuns do Zimbra; o caminho exato do ClamAV incluído e as etapas de recuperação suportadas variam de acordo com a versão do Zimbra Collaboration. Confirme-os com a sua versão instalada antes de fazer alterações.

1. Confirme qual processo do ClamAV está consumindo CPU.

Comece registrando o nome do processo, o uso da CPU, o tempo decorrido e o caminho do comando. Execute este comando como root ou com uma conta que tenha permissão para inspecionar processos do sistema:

ps -eo pid,pcpu,pmem,etime,args | grep -E 'clamd|freshclam'

Em seguida, monitore o processo suspeito por um curto período de tempo com `--process-is-suspeito` top -p PID, substituindo PID`<número>` pelo número obtido no primeiro comando. Uma única leitura não é suficiente para diagnosticar um problema persistente: ` ps--process-is-suspeito` fornece um instantâneo, enquanto ` top--process-is-suspeito` ajuda a verificar se o uso da CPU permanece alto ou diminui após a conclusão de uma verificação ou atualização. Observe também se o caminho pertence ao Zimbra, geralmente localizado em `/usr/local/bin` /opt/zimbra, ou a um pacote separado do sistema operacional.

Se freshclamhouver picos breves e o processo for encerrado ou retornar ao estado ocioso após uma atualização bem-sucedida, isso é diferente de um processo que permanece ocupado. Se clamdo processo for o consumidor contínuo, a verificação de mensagens ou o carregamento do banco de dados são pontos de partida mais prováveis. Não encerre nenhum dos processos apenas porque uma amostra apresentou um pico; primeiro verifique os logs e se o fluxo de e-mails ainda está em andamento.

2. Leia os registros do antivírus antes de alterar as configurações.

O diretório de logs do Zimbra lista os registros do antivírus. Em muitas instalações, inspecione as entradas recentes com:

tail -n 80 /opt/zimbra/log/clamd.log
tail -n 80 /opt/zimbra/log/freshclam.log

Analise os registros de data e hora juntamente com o pico de uso da CPU. Em alguns casos clamd.log, solicitações repetidas de varredura ou mensagens de carregamento do banco de dados podem relacionar o uso da CPU à atividade de e-mail ou à recarga de assinaturas. Em outros casos freshclam.log, uma atualização concluída seguida por um período de inatividade sugere uma atualização de rotina; falhas de conexão repetidas, novas tentativas, erros de checksum ou uma atualização que nunca é concluída exigem uma investigação mais detalhada. Verifique também o log de e-mail do Zimbra aproximadamente no mesmo horário, pois um aumento repentino no número de mensagens recebidas ou no tráfego de anexos pode aumentar as varreduras.

Use a referência de arquivos de log do Zimbra para confirmar os locais dos logs da sua versão. O guia de solução de problemas do FreshClam do ClamAV explica erros comuns do atualizador, incluindo problemas de DNS, download e limite de taxa. Um aviso de que um mecanismo é mais antigo que a versão upstream mais recente do ClamAV não prova, por si só, que o banco de dados está corrompido; o Zimbra inclui um mecanismo testado em uma versão do ZCS.

3. Verifique se há um atualizador duplicado, pouco espaço em disco ou um pico de carga de trabalho.

Antes de ajustar qualquer coisa, descarte as causas comuns que podem manter o serviço ocupado:

• Processos duplicados: Verifique se há mais de um clamdprocesso freshclamduplicado. Um serviço ClamAV instalado separadamente no sistema operacional ou uma tarefa cron personalizada pode estar iniciando uma segunda cópia juntamente com o serviço gerenciado do Zimbra. Não desative um serviço até confirmar qual produto o possui e o que o inicia.
• Pressão do disco: Verifique o espaço disponível e os inodes com ` df -h /opt/zimbrals -l` e `ls -l` df -i /opt/zimbra. Um sistema de arquivos cheio pode impedir atualizações temporárias ou gravações de log e causar novas tentativas. Não remova arquivos de assinatura manualmente para liberar espaço.
• Volume de e-mails: compare o pico de uso da CPU com o volume de mensagens recebidas, o tamanho dos anexos, os e-mails em fila e qualquer entrega em massa recente. Um pico de uso intenso devido a verificações pode aumentar clamdo uso da CPU mesmo quando o serviço está funcionando normalmente.
• Atualize a conectividade: Se freshclamo problema persistir, verifique a resolução de DNS do host, o relógio, a conectividade de saída e quaisquer configurações de proxy necessárias. Corrija o problema subjacente de rede ou proxy em vez de iniciar repetidamente tarefas de atualização manual.

O ClamAV documenta como a configuração do FreshClam controla o comportamento de atualização e o registro de logs em seu manual de configuração . O Zimbra também documenta um atributo de frequência de atualização de definições de vírus, mas seu valor e configuração devem ser verificados para sua versão específica do ZCS. Não reduza a frequência de atualização como uma solução rápida para economizar CPU: assinaturas desatualizadas enfraquecem a proteção, enquanto um DNS ou proxy incorreto continuará falhando independentemente da programação.

4. Aplique a solução menos disruptiva que corresponda às evidências.

Se o clamd estiver ocupado durante um pico de e-mails

Deixe o trabalho atual ser concluído enquanto monitora o uso da CPU e a entrega de e-mails. Se o mesmo padrão se repetir, correlacione-o com o tamanho das mensagens, anexos compactados e volume de entrada. Em seguida, revise a capacidade do servidor e a política de verificação de anexos da sua organização. Evite adicionar limites não documentados ao ClamAV ou excluir tipos de arquivo sem avaliar o impacto na segurança e verificar quais controles o Zimbra suporta na versão instalada.

Se o freshclam falhar repetidamente

Corrija problemas de DNS, proxy, firewall, relógio ou acesso à rede de saída indicados no log. Certifique-se de que apenas o atualizador padrão do Zimbra esteja em execução. Não agende invocações manuais frequentes nem baixe bancos de dados de assinaturas com scripts ad hoc; o ClamAV identifica o FreshClam ou o cvdupdate como métodos de atualização suportados, e a integração padrão do Zimbra deve permanecer como a fonte de informações confiáveis ​​para um servidor Zimbra.

Se o banco de dados parecer corrompido ou o comando clamd não iniciar, ele pode ser iniciado.

Erros como um banco de dados corrompido, falha na verificação de checksum ou falha no carregamento do banco de dados exigem uma recuperação que leve em consideração a versão. O procedimento de redefinição de definições do ClamAV no Zimbra possui instruções diferentes para diferentes gerações do ZCS, incluindo diferentes caminhos binários do FreshClam. Leia o procedimento completo da versão específica que você está executando antes de mover ou reconstruir quaisquer arquivos de banco de dados. Mantenha uma cópia do banco de dados existente até que a recuperação seja confirmada e nunca aplique comandos de um guia de versão antigo sem antes consultar o manual.

Não substitua os binários do ClamAV do Zimbra por uma versão independente do repositório principal como solução de desempenho em primeira instância. A documentação do Zimbra alerta que alterações no mecanismo fora do ciclo de desenvolvimento podem não ser suportadas; use o patch ZCS apropriado ou o caminho de atualização se o próprio mecanismo incluído precisar ser atualizado.

Reinicie o serviço antivírus somente após verificar a causa.

Se o serviço continuar travado após a correção do problema subjacente, uma reinicialização controlada do antivírus pode eliminar um processo obsoleto ou recarregar o banco de dados reparado. Agende essa reinicialização para um momento em que uma breve interrupção na verificação seja aceitável e siga a sequência de comandos para a sua versão do ZCS. Consulte os documentos de procedimento do Zimbra zmantivirusctl stope zmantivirusctl startexecute o comando como o zimbrausuário:

su - zimbra
zmantivirusctl stop
zmantivirusctl start
zmcontrol status

Não utilize uma reinstalação completa zmcontrol stoppara um problema exclusivo do ClamAV, a menos que seu plano de manutenção exija isso. Se o serviço antivírus não voltar a funcionar, preserve os logs relevantes e utilize o canal de suporte ou solução de problemas específico da versão do Zimbra, em vez de reiniciar repetidamente.

5. Verifique se o uso da CPU e a digitalização de e-mails voltaram ao normal.

Após a correção ou reinicialização, repita a verificação do processo e observe a tendência do uso da CPU, em vez de se basear em um único valor instantâneo. Confirme se o processo clamdestá presente, freshclamse não está preso em tentativas repetidas e zmcontrol statusse o antivírus está sendo reportado como em execução. Analise as novas entradas de log para verificar se o carregamento do banco de dados foi bem-sucedido e se não há erros recorrentes de atualização ou verificação. Por fim, verifique se as mensagens de teste normais estão sendo entregues e tratadas de acordo com a política de segurança de e-mail da sua organização.

Uma recuperação bem-sucedida apresenta três sinais observáveis: o processo responsável não consome mais CPU de forma contínua após a conclusão de sua tarefa; os logs param de repetir o mesmo erro; e o fluxo de e-mails e o status do serviço antivírus do Zimbra permanecem saudáveis. Se o uso da CPU permanecer alto, colete um snapshot do processo com registro de data e hora, as entradas correspondentes nos logs de e-mail, os resultados de espaço em disco e a sua versão do ZCS. Essas evidências ajudam a distinguir um defeito real do scanner de um grande volume de e-mails ou um caminho de atualização corrompido clamd.log, freshclam.logsem comprometer a detecção de malware por mera suposição.

Nota sobre a versão: Orientações verificadas em 6 de outubro de 2026. O Centro Técnico do Zimbra inclui referências atuais e páginas de solução de problemas mais antigas e específicas da versão; verifique os comandos e caminhos na documentação da versão do ZCS instalada.