Lorsqu'un amavisdprocessus atteint ou approche les 100 % d'utilisation du processeur, l'objectif n'est pas simplement de le faire disparaître. Une solution efficace doit rétablir le flux normal de messagerie, réduire la latence de traitement, maintenir le fonctionnement des protections anti-spam et antivirus et empêcher la file d'attente de Postfix de continuer à s'allonger.
Dans Zimbra, Amavisd-New fait office d'interface entre le MTA et les analyseurs de contenu. Le guide d'administration Daffodil de Zimbra décrit Amavisd-New comme l'interface entre le MTA Zimbra, ClamAV et SpamAssassin. Par conséquent, une augmentation soudaine de l'utilisation du processeur peut provenir d'Amavisd lui-même, des règles ou du contenu des messages de SpamAssassin, de l'analyse antivirus ou d'une surcharge mobilisant tous les processus disponibles. Consultez le guide d'administration Daffodil de Zimbra .
Un résultat positif se manifeste par quatre signes : l’utilisation du processeur d’Amavis retombe à un niveau stable, les files d’attente différées et actives cessent de croître, les nouveaux messages sont traités sans délai anormal et les services anti-spam et antivirus restent opérationnels. Si la baisse d’utilisation du processeur est uniquement due à la désactivation du filtrage, le problème sous-jacent n’est pas résolu.
Commencez par examiner le système d'exploitation. Ne présumez pas qu'Amavis est responsable simplement parce que la distribution du courrier est lente. Vérifiez les processus les plus sollicités et assurez-vous qu'aucun d'entre eux amavisdn'utilise constamment un cœur de processeur à 100 %.
top -c
ps -eo pid,user,pcpu,pmem,etime,cmd --sort=-pcpu | head -20
Légende : Vue du terminal où amavisd est le principal consommateur de CPU, ce qui est la première condition à vérifier avant de modifier les paramètres de Zimbra.
Une brève augmentation de la charge système peut être normale lors de l'analyse d'un message volumineux ou d'une pièce jointe compressée. Si le même symptôme persiste malgré l'augmentation des délais de messagerie ou de la profondeur de la file d'attente, le problème est considéré comme persistant. Vérifiez également la charge système moyenne, la mémoire libre, l'activité du swap et les temps d'attente d'E/S. Une utilisation élevée du processeur, associée à une forte contention du swap ou du stockage, peut nécessiter une investigation plus approfondie au niveau du système plutôt qu'une simple modification d'Amavis.
Passez à votre compte Zimbra et vérifiez l'état du service. La documentation de Zimbra utilise zmcontrol statuscette méthode comme vérification standard pour les services activés.
su - zimbra
zmcontrol status
zmamavisdctl status
Légende : État du service Zimbra montrant que les composants Amavis, anti-spam, antivirus et MTA sont en cours d’exécution avant le début du dépannage.
Cette étape est importante car « 100 % d’utilisation du processeur » et « service indisponible » correspondent à des modes de défaillance différents. Si Amavis n’est pas en cours d’exécution, examinez plutôt les erreurs de démarrage. Si Amavis est en cours d’exécution mais saturé, poursuivez l’analyse de la file d’attente et des journaux.
La profondeur de la file d'attente indique si une utilisation élevée du processeur affecte la distribution des messages. Consultez la documentation de dépannage des files d'attente de Zimbra zmqstatpour connaître le nombre de messages en file d'attente et les commandes Postfix pour obtenir des informations détaillées sur les messages. Effectuez ces vérifications à plusieurs reprises à quelques minutes d'intervalle.
sudo /opt/zimbra/libexec/zmqstat
postqueue -p
Légende : Les statistiques de file d’attente et les messages différés fournissent une meilleure mesure de l’impact sur le flux de messagerie que le seul pourcentage d’utilisation du processeur.
Cherchez une tendance, pas un chiffre isolé. Une file d'attente qui s'allonge à chaque échantillonnage signifie que le débit est inférieur au taux d'arrivée. Une file d'attente qui diminue régulièrement après une modification est l'un des signes les plus probants que cette modification a été bénéfique.
En cas de déploiement multi-MTA, vérifiez spécifiquement le nœud MTA concerné. Ne présumez pas que la file d'attente sur un autre nœud reflète le même goulot d'étranglement.
Les messages de dépannage d'Amavis et de SpamAssassin sont enregistrés dans le répertoire indiqué /var/log/zimbra.log. Effectuez une recherche aux alentours de l'heure du pic d'utilisation du processeur et corrélez les identifiants des messages, les identifiants des processus et les durées d'analyse.
grep -iE 'amavis|spamassassin|clam' /var/log/zimbra.log | tail -n 200
Légende : Les journaux d’Amavis et de SpamAssassin peuvent indiquer si certains messages ou étapes d’analyse prennent un temps anormalement long.
Les schémas caractéristiques incluent les analyses SpamAssassin longues et répétées, les tentatives répétées pour les mêmes identifiants de file d'attente, les erreurs de communication ClamAV, les échecs liés à la décompression ou un petit ensemble de messages qui monopolisent les ressources du serveur de messagerie. La documentation de dépannage de Zimbra recommande spécifiquement l'activation des journaux de débogage d'Amavis et de SpamAssassin lorsque les délais d'analyse perturbent le flux de messagerie. Consultez le guide de dépannage des journaux de Zimbra .
Zimbra propose des paramètres de journalisation distincts pour Amavis et SpamAssassin. La plage documentée pour Amavis va de 0 à 5, tandis que SpamAssassin zimbraAmavisSALogLevelutilise 0 ou 1. Il est conseillé de commencer par le niveau 2 d'Amavis plutôt que le niveau de verbosité maximal, sauf si un débogage plus approfondi est nécessaire.
su - zimbra
zmprov mcf zimbraAmavisLogLevel 2
zmprov mcf zimbraAmavisSALogLevel 1
Légende : Les modifications temporaires apportées à la journalisation facilitent la corrélation entre le moment de l’analyse et le comportement de SpamAssassin et le pic d’utilisation du processeur.
Reproduisez ou observez le problème uniquement le temps nécessaire pour recueillir des données utiles. Un niveau de journalisation plus élevé augmente les écritures disque et peut rendre un serveur déjà sollicité plus bruyant. Après l'investigation, rétablissez vos valeurs précédentes ; Zimbra indique que le niveau de journalisation par défaut de SpamAssassin est de 0 et celui d'Amavis est généralement faible.
zmprov mcf zimbraAmavisSALogLevel 0
zmprov mcf zimbraAmavisLogLevel 1Si les journaux pointent systématiquement vers SpamAssassin, vérifiez si le problème est survenu après une modification des règles, le déploiement d'une règle personnalisée ou une mise à jour de règle ayant échoué. Des expressions régulières mal conçues et des règles problématiques peuvent engendrer des coûts importants pour certains corps de messages.
La documentation officielle de dépannage d'Amavis de Zimbra décrit la commande de mise à jour intégrée de SpamAssassin pour ZCS 8.8 et versions ultérieures comme suit :
su - zimbra
/opt/zimbra/common/bin/sa-update -D
Légende : La mise à jour des règles SpamAssassin intégrées est appropriée lorsque les journaux ou les erreurs de démarrage indiquent des données de règles obsolètes ou endommagées.
Ne pas considérer cela sa-updatecomme une solution universelle pour le processeur. Si le pic de consommation de ressources a commencé immédiatement après l'ajout d'une règle personnalisée, testez d'abord cette règle. Zimbra stocke les règles SpamAssassin personnalisées modernes sous [emplacement manquant] /opt/zimbra/data/spamassassin/localrules/. Supprimez ou désactivez uniquement la personnalisation suspectée lors d'une période de maintenance contrôlée, puis comparez le temps d'analyse et le comportement de la file d'attente.
Le wiki officiel de Zimbra mentionne également les paramètres de mise à jour automatique des règles et de compilation pour les versions récentes de ZCS. Consultez les stratégies anti-spam de Zimbra avant d'activer le comportement automatisé sur un serveur en production.
Un redémarrage peut débloquer les processus bloqués et charger les règles mises à jour, mais il doit faire suite à un diagnostic et non remplacer le système. Redémarrez d'abord Amavis uniquement, sauf si des éléments indiquent un problème avec l'ensemble de la pile MTA.
su - zimbra
zmamavisdctl restart
Légende : Le redémarrage d’Amavis recharge le service après une modification ciblée des règles ou de la configuration sans redémarrer inutilement tous les services Zimbra.
Si le processeur revient immédiatement à 100 %, c'est un indice utile : la cause est toujours présente. Consultez à nouveau les journaux et vérifiez si le même message, scanner ou règle réapparaît. Redémarrer le service à plusieurs reprises peut atténuer temporairement les symptômes tout en permettant à la file d'attente de se remplir.
Ne considérez pas l'incident comme résolu après avoir constaté une seule baisse du nombre d'utilisateurs du processeur. Vérifiez simultanément la charge du processus, le sens de la file d'attente et l'état du service.
top -c
sudo /opt/zimbra/libexec/zmqstat
zmcontrol status
Légende : La récupération est plus efficace lorsque l’utilisation du processeur, la profondeur de la file d’attente et l’état du service Zimbra s’améliorent simultanément.
Envoyez ensuite un message de test via le MTA concerné et vérifiez qu'il est bien délivré dans les délais de latence habituels. Pour un message qui devrait passer le filtrage, examinez ses en-têtes afin d'y rechercher les champs attendus pour l'analyse antivirus et anti-spam Zimbra/Amavis. Zimbra documente ces en-têtes lorsque X-Virus-Scannedces X-Spam-Statuscontrôles sont activés.
| Ce que vous observez | Meilleure prochaine action | Pourquoi |
|---|---|---|
| Un seul message provoque de longs scans de manière répétée. | Mettez ce message en quarantaine ou examinez-le en toute sécurité et faites correspondre son identifiant de file d'attente avec les journaux. | Le goulot d'étranglement peut être lié au contenu plutôt qu'à la capacité. |
| Le timing de SpamAssassin est dominant | Examiner les règles personnalisées, les mises à jour des règles et les résultats de débogage | Les ensembles de règles comportant de nombreuses expressions régulières ou endommagés peuvent rendre le calcul des scores coûteux. |
| Les erreurs ou les délais d'attente de ClamAV sont prédominants. | Examiner l'état de santé des antivirus et mettre à jour l'état | Amavis attend peut-être simplement le scanner qu'il appelle |
| L'utilisation du processeur est élevée, mais les files d'attente restent proches de zéro. | Observez plus longtemps avant d'apporter des changements perturbateurs | Une utilisation élevée peut être acceptable si le débit et la latence restent satisfaisants. |
| Les files d'attente s'allongent même après les correctifs ciblés. | Passer à l'analyse de capacité, de modèle de message ou de niveau de support | Le serveur peut être sous-dimensionné, subir une attaque ou être confronté à un défaut spécifique au logiciel. |
Ne désactivez pas définitivement l'analyse anti-spam ou antivirus dans le seul but de réduire la charge du processeur. Zimbra prend en charge les dérogations pour certains flux de messagerie de confiance, mais cela modifie le modèle de sécurité et doit faire l'objet d'une décision délibérée concernant la politique de messagerie, et non d'une simple optimisation des performances. La documentation de Zimbra relative à la dérogation de SpamAssassin indique clairement que cette dérogation est liée aux réseaux internes de confiance.
Évitez également d'augmenter le nombre de workers Amavis sans discernement. Un plus grand nombre de workers peut accroître la concurrence, mais aussi la pression sur la mémoire et risque d'aggraver la contention du processeur. La valeur optimale dépend du type de messages, de la taille des pièces jointes, du comportement du scanner, des cœurs disponibles, de la mémoire et des E/S. Testez les modifications en fonction du débit et de la latence de la file d'attente plutôt que de supposer qu'un plus grand nombre de workers est forcément plus rapide.
Cette procédure est conçue pour le cas courant où Amavis est en cours d'exécution mais constamment limité par le processeur. Elle ne remplace pas les instructions du support Zimbra spécifiques à chaque version en cas de défaut produit confirmé, de serveur compromis, d'attaque par déni de service utilisant des messages malformés ou d'architecture multi-nœuds avec des scanners externes.
La documentation technique de la communauté Zimbra recense des cas où des messages spécialement conçus ou le comportement de SpamAssassin pouvaient saturer le processeur des serveurs Amavis pendant des périodes prolongées. L'exposition exacte dépendant des versions de Zimbra et de SpamAssassin installées, il est fortement déconseillé d'appliquer une ancienne procédure de mise à jour sans précaution. Commencez par noter votre version de Zimbra zmcontrol -v, comparez-la avec la version et le niveau de correctifs compatibles, puis suivez les recommandations actuelles du fournisseur pour les mises à jour.
Comparez 10 outils de balayage ping pour une découverte rapide du réseau local, une analyse multiplateforme et la gestion des adresses IP. Découvrez ce qu'un balayage peut – et ne peut pas – vous révéler.
Comparez six outils de gestion de réseau pour la surveillance des performances, notamment la couverture SNMP, la cartographie, les alertes, les modèles de déploiement et les compromis en matière de coûts.
Comparez sept moniteurs de ping gratuits et open source, allant des suites réseau complètes aux sondes de latence ciblées, et choisissez celui qui convient le mieux à vos besoins en matière de disponibilité, de perte de paquets et d'historique.
Comparez les meilleurs analyseurs Wi-Fi pour Windows, iPhone et Android, incluant des outils pour la congestion des canaux, la couverture du signal, les cartes thermiques et le dépannage réseau.
Découvrez ce que signifie la QoS dans le domaine des réseaux, comment les marquages DSCP et les files d'attente de trafic priorisent la voix, la vidéo et les applications professionnelles, et ce que la QoS ne peut pas corriger.
Comparez les logiciels serveurs SFTP fiables pour Windows et Linux, notamment OpenSSH, Bitvise, SolarWinds et SFTPGo. Trouvez la solution idéale pour vos besoins en matière de sécurité et de transfert de fichiers.
Comparez sept outils de gestion d'adresses IP pour la découverte de sous-réseaux, la coordination DNS et DHCP, l'inventaire réseau et l'IPAM open source.
Mettez en place une surveillance réseau pratique avec une couverture claire des périphériques, des indicateurs de performance utiles, des alertes exploitables et une comparaison de SolarWinds NPM, PRTG et OpManager.
Comparez les outils d'analyse réseau pour la découverte rapide des périphériques, les analyses IP multiplateformes et la gestion des identités et des accès IP (IPAM) d'entreprise, avec des conseils pour adapter chaque option à votre réseau.
Utilisez l'option --traceroute de Nmap pour associer les sauts à un hôte autorisé, comprendre les résultats des sauts et du RTT, et résoudre les problèmes de réponses manquantes sans sur-analyse.
