Quando um amavisdprocesso atinge ou se aproxima de 100% de uso da CPU, o objetivo não é simplesmente fazê-lo desaparecer. Uma solução eficaz deve restaurar o fluxo normal de e-mails, reduzir a latência de processamento, manter a proteção anti-spam e antivírus funcionando e impedir que a fila do Postfix continue crescendo.
No Zimbra, o Amavisd-New fica entre o MTA e os analisadores de conteúdo. O guia de administração do Zimbra Daffodil descreve o Amavisd-New como a interface entre o MTA do Zimbra, o ClamAV e o SpamAssassin. Isso significa que um pico de uso da CPU pode ser causado pelo próprio Amavis, pelas regras ou conteúdo das mensagens do SpamAssassin, pela verificação antivírus ou por um acúmulo de processos que mantém todos os nós disponíveis ocupados. Consulte o Guia do Administrador do Zimbra Daffodil .
Um resultado positivo apresenta quatro sinais: o uso da CPU pela Amavis cai para um nível sustentável, as filas de mensagens em espera e ativas param de aumentar, novas mensagens são processadas sem atrasos incomuns e os serviços anti-spam/antivírus permanecem íntegros. Se a queda no uso da CPU se deve apenas à desativação da filtragem, o problema subjacente não foi resolvido.
Comece pelo nível do sistema operacional. Não assuma que a Amavis seja a responsável apenas porque a entrega de e-mails está lenta. Verifique os processos mais utilizados e confirme se um ou mais amavisdprocessos estão consumindo consistentemente um núcleo inteiro da CPU.
top -c
ps -eo pid,user,pcpu,pmem,etime,cmd --sort=-pcpu | head -20
Legenda: Visão do terminal onde o amavisd é o principal consumidor de CPU, condição essencial a ser verificada antes de alterar as configurações do Zimbra.
Um pico curto pode ser normal durante a análise de uma mensagem grande ou anexo compactado. Considere o problema persistente se o mesmo sintoma continuar enquanto houver atrasos nos e-mails ou aumento na profundidade da fila. Verifique também a carga média, a memória livre, a atividade de swap e o tempo de espera de E/S. Alto uso da CPU com forte contenção de swap ou armazenamento pode exigir uma investigação mais abrangente no nível do host, em vez de uma alteração apenas no Amavis.
Acesse a conta Zimbra e verifique o status do serviço. A documentação do Zimbra utiliza zmcontrol statusesse método como verificação padrão para serviços habilitados.
su - zimbra
zmcontrol status
zmamavisdctl status
Legenda: Status do serviço Zimbra mostrando os componentes Amavis, anti-spam, antivírus e MTA em execução antes do início da resolução de problemas.
Esta etapa é importante porque "100% de uso da CPU" e "serviço inativo" são modos de falha diferentes. Se o Amavis não estiver em execução, investigue os erros de inicialização. Se o Amavis estiver em execução, mas sobrecarregado, continue com a análise da fila e dos logs.
A profundidade da fila indica se o alto uso da CPU está afetando a entrega. Consulte os documentos de solução de problemas de filas do Zimbra zmqstatpara obter informações sobre a contagem de filas e os comandos de fila do Postfix para detalhes das mensagens. Execute as verificações repetidamente com alguns minutos de intervalo.
sudo /opt/zimbra/libexec/zmqstat
postqueue -p
Legenda: As estatísticas da fila e as mensagens adiadas fornecem uma medida melhor do impacto no fluxo de e-mails do que apenas a porcentagem de uso da CPU.
Procure por uma direção, não por um número isolado. Uma fila que aumenta a cada amostragem significa que a taxa de transferência está abaixo da taxa de chegada. Uma fila que diminui constantemente após uma mudança é um dos sinais mais fortes de que a mudança realmente ajudou.
Se você estiver executando uma implantação com vários MTAs, verifique especificamente o nó MTA afetado. Não presuma que a fila em outro nó reflita o mesmo gargalo.
As mensagens de solução de problemas do Amavis e do SpamAssassin são gravadas em /var/log/zimbra.log. Pesquise em torno do horário do pico de uso da CPU e correlacione os IDs das mensagens, os IDs dos processos e as durações da verificação.
grep -iE 'amavis|spamassassin|clam' /var/log/zimbra.log | tail -n 200
Legenda: Os registros de mensagens do Amavis e do SpamAssassin podem revelar se mensagens individuais ou etapas de verificação estão demorando mais do que o normal.
Padrões úteis incluem varreduras longas e repetidas do SpamAssassin, tentativas repetidas para os mesmos IDs de fila, erros de comunicação do ClamAV, falhas relacionadas à descompressão ou um pequeno conjunto de mensagens que consomem recursos dos workers repetidamente. A documentação de solução de problemas do Zimbra recomenda especificamente o registro de depuração do Amavis e do SpamAssassin quando atrasos na varredura interrompem o fluxo de e-mails. Consulte a referência de solução de problemas de registro do Zimbra .
O Zimbra expõe controles de registro separados para Amavis e SpamAssassin. O intervalo documentado para o Amavis é de 0 a 5, enquanto o SpamAssassin zimbraAmavisSALogLevelusa 0 ou 1. Comece com o nível 2 do Amavis em vez da verbosidade máxima, a menos que precise de uma depuração mais aprofundada.
su - zimbra
zmprov mcf zimbraAmavisLogLevel 2
zmprov mcf zimbraAmavisSALogLevel 1
Legenda: Alterações temporárias no registro de logs facilitam a correlação entre o tempo de varredura e o comportamento do SpamAssassin com o pico de uso da CPU.
Reproduza ou observe o problema apenas pelo tempo necessário para coletar dados úteis. Um nível de registro mais alto aumenta as gravações em disco e pode tornar um servidor ocupado mais ruidoso. Após a investigação, retorne aos valores anteriores; a Zimbra documenta o nível de registro padrão do SpamAssassin como 0 e o registro do Amavis como normalmente de baixo volume.
zmprov mcf zimbraAmavisSALogLevel 0
zmprov mcf zimbraAmavisLogLevel 1Se os registros apontarem consistentemente para o SpamAssassin, verifique se o problema começou após uma alteração nas regras, a implementação de uma regra personalizada ou uma atualização de regra com falha. Expressões regulares mal elaboradas e regras problemáticas podem se tornar custosas em determinados corpos de mensagem.
O material oficial de resolução de problemas da Zimbra para o Amavis documenta o comando de atualização do SpamAssassin incluído para o ZCS 8.8 e versões posteriores da seguinte forma:
su - zimbra
/opt/zimbra/common/bin/sa-update -D
Legenda: Atualizar as regras do SpamAssassin incluídas é apropriado quando os registros ou erros de inicialização apontam para dados de regras desatualizados ou corrompidos.
Não considere isso sa-updatecomo uma solução universal para o problema de CPU. Se o pico de uso de CPU começou imediatamente após a adição de uma regra personalizada, teste essa regra primeiro. O Zimbra armazena regras personalizadas modernas do SpamAssassin em um diretório específico /opt/zimbra/data/spamassassin/localrules/. Remova ou desative apenas a personalização suspeita durante uma janela de manutenção controlada e, em seguida, compare o tempo de verificação e o comportamento da fila.
A wiki oficial do Zimbra também menciona as configurações de atualização e compilação automática de regras para versões mais recentes do ZCS. Consulte as estratégias antispam do Zimbra antes de ativar o comportamento automatizado em um servidor já em funcionamento.
Uma reinicialização pode liberar processos travados e carregar regras atualizadas, mas deve ser feita após o diagnóstico, e não como substituto. Reinicie apenas o Amavis primeiro, a menos que as evidências apontem para um problema em toda a pilha MTA.
su - zimbra
zmamavisdctl restart
Legenda: Reiniciar o Amavis recarrega o serviço após uma alteração específica nas regras ou na configuração, sem a necessidade de reiniciar todos os serviços do Zimbra.
Se o uso da CPU retornar imediatamente a 100%, isso é uma evidência útil: a causa ainda está presente. Volte aos registros e identifique se a mesma mensagem, scanner ou regra aparece novamente. Reiniciar o serviço repetidamente pode reduzir temporariamente os sintomas, permitindo que a fila cresça.
Não considere o incidente resolvido após observar uma queda no número de CPUs uma única vez. Verifique simultaneamente a carga do processo, a direção da fila e a integridade do serviço.
top -c
sudo /opt/zimbra/libexec/zmqstat
zmcontrol status
Legenda: A recuperação é mais eficaz quando o uso da CPU, a profundidade da fila e o status do serviço Zimbra melhoram simultaneamente.
Em seguida, envie uma mensagem de teste através do MTA afetado e confirme se ela foi entregue dentro da sua faixa de latência normal. Para uma mensagem que deveria passar pela filtragem, inspecione seus cabeçalhos em busca dos campos esperados de verificação de spam e vírus do Zimbra/Amavis. O Zimbra documenta cabeçalhos como `spam` X-Virus-Scannede `virus` X-Spam-Statusquando essas verificações estão ativas.
| O que você observa | Melhor próxima ação | Por que |
|---|---|---|
| Uma única mensagem causa varreduras demoradas repetidamente. | Coloque essa mensagem em quarentena ou inspecione-a com segurança e correlacione seu ID na fila com os registros. | O gargalo pode estar relacionado ao conteúdo específico, e não à capacidade. |
| O timing do SpamAssassin domina | Analise regras personalizadas, atualizações de regras e a saída de depuração. | Conjuntos de regras com muitas expressões regulares ou corrompidos podem encarecer a pontuação. |
| Os erros ou timeouts do ClamAV predominam. | Investigar a saúde do antivírus e atualizar o estado | A Amavis pode simplesmente estar aguardando o scanner que ela chama. |
| O uso da CPU está alto, mas as filas permanecem próximas de zero. | Observe por mais tempo antes de fazer mudanças disruptivas. | A alta utilização pode ser aceitável se a taxa de transferência e a latência permanecerem estáveis. |
| As filas continuam a crescer mesmo após correções específicas. | Escalar para análise de capacidade, padrão de mensagens ou nível de suporte. | O servidor pode estar subdimensionado, sob ataque ou apresentando uma falha específica do software. |
Não desative permanentemente a verificação anti-spam ou antivírus apenas para reduzir o uso da CPU. O Zimbra oferece suporte a políticas de bypass para tráfego específico de origem confiável, mas isso altera o modelo de segurança e deve ser uma decisão deliberada de política de e-mail, não um ajuste genérico de desempenho. A documentação do Zimbra para bypass de SpamAssassin deixa claro que o bypass está vinculado a redes internas confiáveis.
Evite também aumentar indiscriminadamente o número de workers do Amavis. Mais workers podem aumentar a concorrência, mas também aumentam a pressão sobre a memória e podem piorar a contenção da CPU. O valor correto depende da combinação de mensagens, do tamanho dos anexos, do comportamento do scanner, dos núcleos disponíveis, da memória e da E/S. Teste as alterações em relação à taxa de transferência e à latência da fila, em vez de presumir que um pool de workers maior seja mais rápido.
Este procedimento foi desenvolvido para o caso comum em que o Amavis está em execução, mas persistentemente sobrecarregado pela CPU. Ele não substitui as orientações de suporte específicas da versão do Zimbra para defeitos confirmados do produto, servidores comprometidos, campanhas de negação de serviço com mensagens malformadas ou arquiteturas com múltiplos nós e scanners externos.
O material técnico da comunidade Zimbra documentou casos históricos em que mensagens especialmente criadas ou o comportamento do SpamAssassin podiam deixar os workers da Amavis sobrecarregados por longos períodos. Como a exposição exata depende das versões do Zimbra e do SpamAssassin instaladas, não aplique cegamente um procedimento antigo de atualização de pacotes. Primeiro, registre sua versão do Zimbra com `zimbra version` zmcontrol -v, compare-a com a versão e o nível de patch suportados e siga as orientações atuais do fornecedor para atualizações.
Compare 10 ferramentas de varredura de ping para descoberta rápida de LAN, varredura multiplataforma e gerenciamento de endereços IP. Saiba o que uma varredura pode — e não pode — revelar.
Compare seis ferramentas de gerenciamento de rede para monitoramento de desempenho, incluindo cobertura SNMP, mapeamento, alertas, modelos de implantação e custo-benefício.
Compare as melhores opções de analisadores de Wi-Fi para Windows, iPhone e Android, incluindo ferramentas para congestionamento de canais, cobertura de sinal, mapas de calor e solução de problemas de rede.
Compare sete monitores de ping gratuitos e de código aberto, desde suítes completas de rede até sondas de latência específicas, e escolha a opção mais adequada para disponibilidade, perda de pacotes e histórico.
Veja como a taxa de transferência de rede difere da largura de banda, o que causa desempenho lento ou instável e quais ferramentas podem testar um caminho ou monitorar o tráfego.
Compare softwares de servidor SFTP confiáveis para Windows e Linux, incluindo OpenSSH, Bitvise, SolarWinds e SFTPGo. Encontre a solução ideal para suas necessidades de segurança e transferência de arquivos.
Crie um monitoramento de rede prático com cobertura clara de dispositivos, métricas de desempenho úteis, alertas acionáveis e uma comparação entre SolarWinds NPM, PRTG e OpManager.
Compare sete ferramentas de gerenciamento de endereços IP para descoberta de sub-redes, coordenação de DNS e DHCP, inventário de rede e IPAM de código aberto.
Compare ferramentas de varredura de rede para descoberta rápida de dispositivos, varreduras de IP multiplataforma e IPAM corporativo, com orientações sobre como escolher a opção mais adequada para sua rede.
Compare seis ferramentas de monitoramento de rede Linux para descoberta de dispositivos SNMP, gráficos de interface, métricas de host, verificação de serviços e fluxos de tráfego.
