Analyse des goulots d'étranglementAnalyse des goulots d'étranglementCe document présente le programme qshape(1) qui aide l'administrateur à voir la distribution des messages dans la file d'attente triés par date, expéditeur ou domaine destinataire. qshape(1) est fournit avec les sources de Postfix 2.1 source sous le répertoire "auxiliary".
Pour comprendre la sortie de qshape(1), il est préférable de connaître les différentes files d'attente de Postfix. À cette fin, le rôle de chaque répertoire de file d'attente de Postfix est descrite brièvement dans les paragraphes "Info supplémentaire : répertoires de file d'attente de Postfix" à la fin de ce document.
Ce document couvre les sujets suivants :
Lorsque le courrier est traité lentement ou la file d'attente est anormalement chargée, lancez qshape(1) en tant que super-utilisateur (root) pour faciliter la résolution du problème. Le programme qshape(1) montre une vue du contenu de la file d'attente de Postfix sous forme de tableau.
Sur l'axe horizontal, il montre l'âge des messages avec une granularité plus fine pour les messages récents.
L'axe vertical est renseigné avec les domaines de destination (ou d'expédition avec l'option "-s"). Les domaines concernés par le plus grand nombre de messages sont listés en premier.
Par exemple sur la sortie ci-dessous, nous voyons les 10 premières lignes des domaines d'expédition (courrier souvent forgé) de la "file d'attente hold (spam) :
$ qshape -s hold | head
T 5 10 20 40 80 160 320 640 1280 1280+
TOTAL 486 0 0 1 0 0 2 4 20 40 419
yahoo.com 14 0 0 1 0 0 0 0 1 0 12
extremepricecuts.net 13 0 0 0 0 0 0 0 2 0 11
ms35.hinet.net 12 0 0 0 0 0 0 0 0 1 11
winnersdaily.net 12 0 0 0 0 0 0 0 2 0 10
hotmail.com 11 0 0 0 0 0 0 0 0 1 10
worldnet.fr 6 0 0 0 0 0 0 0 0 0 6
ms41.hinet.net 6 0 0 0 0 0 0 0 0 0 6
osn.de 5 0 0 0 0 0 1 0 0 0 4
La colonne "T" montre le total des messages (émis dans ce cas) pour chaque domaine. Les colonnes suivantes montre le nombre de messages par tranche d'âge. La ligne nommée "TOTAL" montre le total pour tous les domaines.
Dans cet exemple, il y a 14 messages issus de yahoo.com, 1 datant dont l'âge se situe entre 10 et 20 minutes, 1 entre 320 et 640 minutes, et 12 âgés de plus de 1280 minutes (1 jour vaut 1440 minutes).
Par défaut, qshape montre les statistiques cumulées des files d'attente entrante et active qui sont les plus significatives pour analyser les performances.
On peut faire une requête sur une liste de files d'attente alternative :
$ qshape deferred | less $ qshape incoming active deferred | less
qui montrera la ditribution des messages de la file d'attente retardée ou le total des files d'attente active et retardée.
Les options de la ligne de commande contrôlent le nombre de lignes affichées, l'âge limite inférieur, le compte par domaine parent, et ainsi de suite. L'option "-h" présente un résumé des options disponibles.
Les grands nombres sur la sortie de qshape représentent de grands nombres de messages destinés à (ou provenant de) un domaine particulier. Il devrait être possible de distinguer les domaines dont le nombre de message en attente est majoritairement du courrier entrant ou sortant.
Le problème des domaines expéditeurs ou destinataires apparaît au coin supérieur gauche du tableau de sortie. Souvenez-vous que la file d'attente active ne peut contenir plus de 20000 ($qmgr_message_active_limit) messages. Pour savoir si cette limite a été atteinte, utilisez :
$ qshape -s active | head (montre les statistiques expéditeurs)
Si le compteur d'expédition est en deça de 20000, la file d'attente active n'est pas saturée, le domaine le plus chargé apparaît en haut du tableau.
La file d'attente active est également limitée à 20000 adresses de destination ($qmgr_message_recipient_limit). Pour connaître le niveau de saturation, utilisez :
$ qshape active | head (montre les statistiques destinataires)
En ayant trouvé le domaine le plus chargé, il est souvent intéressant de chercher les logs récents concernant les messages appartenant au domaine en question.
# Recherche des livraisons à destination de exemple.com
#
$ tail -10000 /var/log/maillog |
egrep -i ': to=<.*@exemple\.com>,' |
less
# Recherche des messages provenant de exemple.com
#
$ tail -10000 /var/log/maillog |
egrep -i ': from=<.*@exemple\.com>,' |
less
Si vous voulez suivre le chemin d'un message particulier (à partir de son id) :
# Recherche les logs concernant le message dont l'id est 2B2A73FF68. # $ tail -10000 /var/log/maillog | egrep ': 2B2173FF68: '
Observez également les messages d'attention du gestionnaire des files d'attente dans les logs. Ils peuvent suggérer une stratégie pour réduire les congestions.
$ egrep 'qmgr.*(panic|fatal|error|warning):' /var/log/maillog
Lorsque tous les tests échouent, essayez la liste de diffusion de Postfix pour obtenir de l'aide, mais n'oubliez pas d'inclure les 10 ou 20 premières lignes de la sortie de qshape(1).
Lors de l'examen des files d'attente entrante et active, dans des conditions normales (pas de congestion), ces files sont quasiment vides. Le courrier est expédié quasiment instantanément ou est retardé sans congestion dans la file d'attente active.
$ qshape (show incoming and file d'attente active status)
T 5 10 20 40 80 160 320 640 1280 1280+
TOTAL 5 0 0 0 1 0 0 0 1 1 2
meri.uwasa.fi 5 0 0 0 1 0 0 0 1 1 2
Si quelqu'un examine ces files séparément, la file d'attente entrante est vide ou contient ponctuellement un ou deux messages, alors que la file d'attente active contient plus de messages, âgés pour certains :
$ qshape incoming
T 5 10 20 40 80 160 320 640 1280 1280+
TOTAL 0 0 0 0 0 0 0 0 0 0 0
$ qshape active
T 5 10 20 40 80 160 320 640 1280 1280+
TOTAL 5 0 0 0 1 0 0 0 1 1 2
meri.uwasa.fi 5 0 0 0 1 0 0 0 1 1 2
Ceci provient d'un serveur où la validation des destinataires n'est pas disponible pour certains des domaines hébergés. Les attaques par dictionnaire sur le domaine non contrôlé engendre de nombreux messages de rejet. Ils surchargent la file d'attente, mais avec de bon réglages, ils ne saturent pas les files d'attente entrante ou active. Le très grand volume de messages retardés n'est pas une cause directe d'alarme.
$ qshape deferred | head
T 5 10 20 40 80 160 320 640 1280 1280+
TOTAL 2234 4 2 5 9 31 57 108 201 464 1353
heyhihellothere.com 207 0 0 1 1 6 6 8 25 68 92
pleazerzoneprod.com 105 0 0 0 0 0 0 0 5 44 56
groups.msn.com 63 2 1 2 4 4 14 14 14 8 0
orion.toppoint.de 49 0 0 0 1 0 2 4 3 16 23
kali.com.cn 46 0 0 0 0 1 0 2 6 12 25
meri.uwasa.fi 44 0 0 0 0 1 0 2 8 11 22
gjr.paknet.com.pk 43 1 0 0 1 1 3 3 6 12 16
aristotle.algonet.se 41 0 0 0 0 0 1 2 11 12 15
Les domaines montrés sont de fréquents véhicules de spam et le plus grand volume se trouve dans les colonnes correspondant aux messages les plus âgés, montrant ainsi que les taux d'arrivée sont modérés. Les grands nombres sur des messages d'âge faible sont plus significatifs de problèmes. Les vieux messages n'allant nul part sont d'autant moins gênant que les files d'attente active et entrante sont faiblement chargées. Nous pouvons également voir que les messages non-livrables groups.msn.com sont arrivent avec un taux si faible qu'il ne s'agit pas d'une attaque par dictionnaire.
$ qshape -s deferred | head
T 5 10 20 40 80 160 320 640 1280 1280+
TOTAL 2193 4 4 5 8 33 56 104 205 465 1309
MAILER-DAEMON 1709 4 4 5 8 33 55 101 198 452 849
exemple.com 263 0 0 0 0 0 0 0 0 2 261
exemple.org 209 0 0 0 0 0 1 3 6 11 188
exemple.net 6 0 0 0 0 0 0 0 0 0 6
exemple.edu 3 0 0 0 0 0 0 0 0 0 3
exemple.gov 2 0 0 0 0 0 0 0 1 0 1
exemple.mil 1 0 0 0 0 0 0 0 0 0 1
En regardant la distribution des expéditeurs, nous voyons que la plupart des messages sont des rejets.
Cet exemple est pris sur une discussion de février 2004 sur la liste de diffusion des utilisateurs de Postfix. La congestion a été rapportée avec de grandes files d'attente active et entrante et des nombres de processus d'agent de livraison proches des limites. Le fil de cette discussion est archivé ici : http://groups.google.com/groups?th=636626c645f5bbde
En utilisant une version ancienne de qshape(1) on voyait seulement les messages de quelsues destinations :
$ qshape (montre les statuts des files d'attente entrante et active)
T A 5 10 20 40 80 160 320 320+
TOTAL 11775 9996 0 0 1 1 42 94 221 1420
user.sourceforge.net 7678 7678 0 0 0 0 0 0 0 0
lists.sourceforge.net 2313 2313 0 0 0 0 0 0 0 0
gzd.gotdns.com 102 0 0 0 0 0 0 0 2 100
La colonne "A" montre le nombre de messages de la file d'attente active, et les colonnes numérotées montrent les totaux pour la file d'attente retardée. À 10000 messages (taille limite de la file d'attente active de Postfix 1.x) la file d'attente active est pleine. La file entrante se chargeait rapidement.
Avec les destinations à problème clairement identifiées, l'administrateur a rapidement trouvé et solutionné le problème. Il est nettement plus difficile d'obtenir ces mêmes informations des logs. Bien que une lecture attentive de la sortie de mailq(1) donnerait des résultats similaires, il est plus difficile de jauger l'ampleur du problème en regardant les messages en file d'attente.
Lorsqu'un site à qui vous envoyés beaucoup de messages est arrêté ou lent, les messages encombrent rapidement la file d'attente retardée, ou pire, la file d'attente active. La sortie de qshape montrera de grands nombres pour les domaines destinataires de tous les âges à partir du début du problème :
$ qshape deferred | head
T 5 10 20 40 80 160 320 640 1280 1280+
TOTAL 5000 200 200 400 800 1600 1000 200 200 200 200
highvolume.com 4000 160 160 320 640 1280 1440 0 0 0 0
...
Ici, la destination "highvolume.com" continue d'accumuler du courrier retardé. Les files d'attente entrante et active sont faiblement chargées, mais la file d'attente retardée a commencé à se charger 1 à 2 heures plus tôt et continue à grandir.
Si la destination en cause n'est pas arrêtée, mais seulement ralentie, on peut voir une congestion similaire dans la file d'attente active. Ce dernier type de congestion est plus alarmant ; on doit prendre des mesures pour s'assurer que le courrier soit retardé ou ajouter une règle d'accès demandant aux expéditeurs d'essayer d'envoyer leur courrier ultérieurement.
Si une destination à grand volume montre souvent ces signes suite à des connexions refusées par toutes ses machines MX ou avec la mention "421 Server busy errors", il est possible que le gestionnaire des files d'attente marque cette destination comme "morte" en dépit de la nature des erreurs. La destination sera réessayée plus tard après expiration du délai $minimal_backoff_time. Si les erreurs sont assez fréquentes, il peut n'y avoir que peut de messages livrés avant que la destination ne soit marquée "morte".
Le MTA qui a été observé le plus fréquemment présentant ces signes est Microsoft Exchange, qui refuse les connexions sous la charge. Certains scanners-proxies antivirus en coupure du serveur Exchange propagent les connexions refusées au client avec le code "421" error.
Notez qu'il est désormais possible de configurer Postfix pour présenter des caractéristiques similaires en configurant mal le serveur anvil(8) (non inclus dans Postfix 2.1). N'utilisez pas anvil(8) pour limiter les taux, son but est la prévention des DoS (dénis de service) et la limite du taux doit être très généreuse !
À long terme, il est souhaité que la détection des machines mortes de Postfix et le mécanisme de contrôle de concurrence soit plus tolérant aux "nuisibles". Pour ceux qui doivent livrer un volume important de courrier vers une destination qui montre souvent ce genre d'erreurs, il y a un subtil contournement.
Dans master.cf créez un clone du transporteur "smtp" dédié pour la destination en question.
Dans master.cf configurez une limite de processus raisonnable pour ce transporteur (typiquement un nombre comris entre 10 et 20).
IMPORTANT!!! Dans main.cf configurez une très large limite de concurrence initiale vers cette destination (200).
/etc/postfix/main.cf:
initial_destination_concurrency = 200
transportname_destination_concurrency_limit = 200
Où transportname est le nom de l'entrée master.cf en question.
La conséquence de cette configuration surprenante est que 200 erreurs consécutives sont tolérées sans marquer cette destination comme morte tout en maintenant une concurrence raisonnable (10 à 20 processus). Cette astuce doit être réservée à des situations particulières : volume élevé de livraisons dans un canal capable de recevoir un grand nombre de messages mais régulièrement perturbé par des erreurs.
Lorsqu'une destination est incapable de tenir la charge même après que la limite des processus Postfix ait été réduite à 1, en désespoir on peut insérer un bref délai entre deux tentatives de livraison.
Dans l'entrée de la table transport correspondant à la destination à problème, indiquez une machine morte comme premier saut.
Dans l'entrée du fichier master.cf correspondant au transporteur, indiquez la destination à problème comme fallback_relay et indiquez une petite valeur smtp_connect_timeout.
/etc/postfix/transport:
problem.exemple.com slow:[dead.host]
/etc/postfix/master.cf:
# service type private unpriv chroot wakeup maxproc command
slow unix - - n - 1 smtp
-o fallback_relay=problem.exemple.com
-o smtp_connect_timeout=1
Cette solution oblige le client smtp(8) de Postfix à attendre $smtp_connect_timeout secondes entre les livraisons. Cette solution dépend des détails de management des connexions, et doit être revue lorsque le cache des connexions SMTP est introduit.
Heureusement, une solution plus élégante à ces problèmes sera trouvée dans le futur.
Les paragraphes suivants décrivent les files d'attente de Postfix : leur but, leur aspect normal et comment diagnostiquer les situations anormales.
Les messages soumis via la commande sendmail(1) de Postfix mais pas encore déposés dans la file d'attente principale de Postfix par le service pickup(8), attendent dans la file d'attente "maildrop". Des messages peuvent être ajoutés à la file d'attente "maildrop" même lorsque le système Postfix ne fonctionne pas. Ils seront pris en charge au démarrage de Postfix.
La file d'attente "maildrop" n'est gérée que par le service mono-thread pickup(8) qui l'examine périodiquement ou lorsque une notification d'arrivée est transmise par le programme postdrop(1). Le programme postdrop(1) est un programme d'aide setgid qui permet à un utilisateur non privilégié d'utiliser le programme sendmail(1) de Postfix pour injecter du courrier dans la file d'attente "maildrop" et notifier cette arrivée au service pickup(8).
Tous les messages entrant dans la file d'attente principale de Postfix passent par le service cleanup(8). Ce service est responsable de la réécriture de l'enveloppe et des en-têtes, de l'examen par expressions rationnelles des en-têtes et du corps, de l'ajout automatique des destinataires cachés (BCC) et garantie l'insertion du message dans la "file d'attente entrante" de Postfix.
En l'absence de consommation excessive de CPU lors de l'examen des en-têtes et du corps par cleanup(8) ou par un autre logiciel, la performance est de l'ordre de la capacité d'entrées/sortie du disque. Le taux auquel le service pickup(8) peut injecter du courrier dans la file d'attente est grandement déterminé par les temps d'accès au disque jusqu'à ce que le service cleanup(8) valide le stockage du message avant de retourner un code de succès. C'est également vrai pour les écritures de messages dans le répertoire "maildrop" par le programme postdrop(1).
Comme le service pickup est mono-thread, il ne peut livrer qu'un message à la fois à un rythme qui ne peut excéder les capacités d'entrées/sorties du disque (+ CPU si non négligeable) du service cleanup.
Une congestion dans cette file d'attente est significative d'une soumission locale excessive de messages ou peut-être d'une consommation excessive de CPU par le service cleanup(8) due à une table body_checks excessive.
Notez que si la file d'attente active est pleine, le service cleanup tentera de ralentir l'injection de message en attendant $in_flow_delay secondes avant chaque message. Dans ce cas, la congestion de la file d'attente "maildrop" congestion risque d'être une conséquence de la congestion en aval en non un problème en soi.
Notez également qu'on ne doit pas tenter de livrer un grand volume de messages via le service pickup(8). Les sites à fort trafic doivent éviter les filtres de contenu qui réinjectent le courrier examiné via les commandes Postfix sendmail(1) et postdrop(1).
Un fort taux d'arrivée de messages soumis localement peut être une indication de boucles de message ou d'un programme de notifications emballé. Essayez de garder le volume de messages injectés localement à un niveau modéré.
La commande "postsuper -r" peut placer des messages sélectionnés dans la file d'attente "maildrop" pour réeffectuer le processus. C'est commode pour remettre à jour les paramètres de filtrage de contenu content_filter. Remettre en file d'attente un grand nombre de messages en utilisant "postsuper -r" peut clairement causer un pic de taille dans la file d'attente "maildrop".
L'administrateur peut définir des politiques d'accès(5) "smtpd", ou des examens d'en-têtes/du corps par le service cleanup(8) transférant automatiquement les messages de la file d'attente normale vers la file d'attente "hold". Les messages placés dans la file d'attente "hold" y restent jusqu'à intervention de l'administrateur. Aucune tentative de livraison périodique n'a lieu dans la file d'attente "hold". La commande postsuper(1) peut être utilisée manuellement pour renvoyer ces messages dans la file d'attente "retardée".
Des messages peuvent potentiellement rester dans la file d'attente "hold" pour un temps supérieur à l'espérance de vie maximale en file d'attente (après laquelle ils sont renvoyés à l'expéditeur). Si de tels "vieux" messages doivent être enlevés de la file d'attente "hold", ils doivent généralement être déplacés dans la file d'attente "maildrop", ainsi ils récupèrent une nouvelle marque de temps et ont plus de chances d'être livrés. Les messages "jeunes" peuvent être déplacés directement dans la file d'attente "retardée".
La file d'attente "hold" joue un petit rôle dans les performances de Postfix, car son but est plus de traquer le spam que d'améliorer les performances.
Tous les nouveaux messages entrant dans Postfix sont écrits par le service cleanup(8) dans la file d'attente "entrante". Les nouveaux fichiers sont créés par l'utilisateur "postfix" avec des droits d'accès 0600. Lorsqu'un fichier est prêt à être traité, le service cleanup(8) change ces droits en 0700 et notifie l'arrivée au gestionnaire des files d'attente. Le gestionnaire des files d'attente ignore les fichiers incomplets dont les droits sont positionnés à 0600, considérant qu'ils sont encore traités par cleanup.
Le gestionnaire des files d'attente examine la file d'attente entrante envoyant tout nouveau message dans la file d'attente "active" si la limite de celle-ci n'est pas dépassée. Par défaut, la file d'attente active peut contenir 20000 messages. Une fois la limite de la file d'attente active atteinte, le gestionnaire des files d'attente arrête d'examiner la file entrante (ainsi que la file retardée, voir ci-dessous).
Dans des conditions normales, la file d'attente entrante est quasiment vide (elle n'a que des fichiers en mode 0600), et le gestionnaire des files d'attente peut importer les nouveaux messages dans la file d'attente active au fur et à mesure qu'ils arrivent.
La file d'attente entrante augmente dès que le taux de messages entrant dépasse le taux auquel le gestionnaire des files d'attente peut importer les messages dans la file d'attente active. Le principal facteur de ralentissement du gestionnaire des files d'attente est du aux requêtes de transport effectuées auprès du service trivial-rewrite. Si le gestionnaire des files d'attente est ordinaire chargé, évitez les services de consultation "lents" (MySQL, LDAP, ...) pour la recherche du transporteur ou accélérez les machines qui fournissent ce service.
Le paramètre in_flow_delay est utilisé pour limiter le taux d'arrivée lorsque le gestionnaire des files d'attente commence à faiblir. Le service cleanup(8) attendra $in_flow_delay secondes avant de créer un nouveau fichier en file d'attente s'il ne peut obtenir de "jeton" du gestionnaire des files d'attente.
Depuis que le nombre de processus cleanup(8) est limité dans la plupart des cas par la concurrence des serveurs SMTP, le taux d'entrée peut excéder le taux de sortie de plus de "nb de connexions SMTP" / $in_flow_delay messages par secondes.
Avec une limite de processus à 100 et un in_flow_delay de 1 seconde, le couple est assez fort pour limiter un injecteur simple à 1 message par seconde, mais pas assez pour infléchir un taux d'entrée excessif provenant de plusieurs sources au même moment.
Si un serveur est attaqué depuis plusieurs directions, augmentez in_flow_delay à 10 secondes seulement si la file d'attente entrante augmente alors même que la file d'attente active n'est pas remplie et que le service trivial-rewrite utilise un mécanisme de recherche du transporteur rapide.
Le gestionnaire des files d'attente est un ordonnaceur d'agent de livraison ; il travaille à assurer une livraison rapide et sûre des messages vers toutes les destinations avec les limites des ressources.
La file d'attente active est assez analogue à une file d'attente d'un processus fonctionnant dans un système d'exploitation. Les messages dans la file d'attente active sont prêts à être envoyés (runnable), mais ne sont pas nécessairement sur le point d'être envoyé (running).
Alors que beaucoup d'administrateurs Postfix pensent que la file d'attente "active" est un répertoire sur disque, la réelle file d'attente "active" est un ensemble de structures de données dans la mémoire du processus gestionnaire des files d'attente.
Les messages dans les files d'attente "maildrop", "hold", "incoming" et "retardée" (ci-dessous) n'occupent pas la memoire ; ils sont stockés en sécurité sur le disque attendant leur tour. Les informations d'enveloppe des messages en file d'attente "active" sont gérées en mémoire, autorisant le gestionnaire des files d'attente à ordonnancer globalement, allouer les processus agent de livraison disponibles au message approprié de la file d'attente active.
Dans la file d'attente active, les messages (multi-destinataires) sont coupés en groupes de destinataires qui partagent la même combinaison transport/saut-suivant ; la taille du groupe est limités par la limite de concurrence de destinataires du transporteur.
Les groupes de destinataires multiples (d'un ou plusieurs messages) sont mis en file d'attente pour la livraison via la combinaison transport/saut-suivant. La limite de concurrence de destination du transporteur désigne le nombre de tentatives de livraison simultanées pour chaque saut suivant. Les transporteurs dont la limite de destinataires concurrents est fixée à 1 sont spéciaux : ils sont groupés par adresse de destination actuelle plutôt que par saut suivant, activant ainsi les limites de concurrence par destinataire plutôt que par domaine. Les limites par destinataire sont plus appropriées à la livraison finale aux boîtes-aux-lettres qu'au transfert à un autre serveur.
Des congestions apparaissent dans la file d'attente active lorsqu'une ou plusieurs destinations reçoivent à un taux plus lent que le taux de message entrant correspondant. Si une destination est "morte" pendant un certain temps, le gestionnaire des files d'attente la marquera comme tel, et retardera immédiatement tous les messages pour cette destination sans essayer de les assigner à un agent de livraison. Dans ce cas les messages seront rapidement retirés de la file d'attente active et mis dans la file retardée. Si la destination est simplement ralentie, ou s'il y a un problème du à un taux d'arrivée trop élevée, la file d'attente active grossira et sera dominée par les messages dont la destination est congestionnée.
La seule manière de réduire la congestion est soit de réduire le taux d'entrée soit d'augmenter le taux de sortie. Cette dernière proposition se traduit soit par une augmentation de la concurrence soit par la réduction de la latence de livraison.
Pour des sites à fort volume, un paramètre clef est le nombre d'agents de livraisons "smtp" autorisés pour les transports "smtp" et "relay". Ces sites ont tendance à envoyer à beaucoup de destinations dont beaucoup peuvent être mortes ou ralenties, donc une bonne fraction des agents de livraison disponibles seront bloqués attendant ces sites ralentis. Ainsi le courrier déstiné au monde entier engendrera des latences, ainsi le seul moins d'augmenter la capacité de sortie est d'augmenter la concurrence des agents de livraisons.
La limite par défaut des processus "smtp" fixée à 100 est assez élevée pour beaucoup de sites et peut être abaissée pour els sites disposant d'une faible bande passante (à n'utiliser que si le réseau est saturé). Lorsqu'on trouve que la file d'attente croît sur un système "peu actif" (CPU, I/O disque et réseau non saturés) la raison résultante de la congestion est une insuffisante concurrence face à la charge. Si le nombre de connexions sortantes SMTP (en état ESTABLISHED ou SYN_SENT) atteint la limite des processus, que le courrier est traité lentement et que le système et le réseau ne sont pas chargés, augmentez la limie des processus "smtp" et/ou "relay" !
En particulier pour le transporteur "relay", diminuez le temps limite des connexions SMTP (1 à5 secondes) et augmentez la limite par défaut de concurrence par destination. Prenez en compte la latence en question lorsque 1 sur N des machines MX est hors service pour un site à fort volume et assurez vous que la concurrence configurée divisée par cette latence dépasse le taux de messages requis. Si vous gérez la destination, utilisez des répartisseur de charge devant un groupe de machines MX. Ces équipements ont un meilleur MTBF et peuvent masquer les arrêts individuels de serveurs MX.
Si nécessaire, dédiez et optimisez un transporteur personnalisé pour ces destinations à fort volume.
Une autre cause commune de congestion est un vidage non garanti de la file d'attente retardée entière. La file d'attente retardée contient les messages dont la première tentative de livraison a échoué et risquent de ralentir la livraison (timeouts). Ceci signifie que la réaction la plus commune face une grosse file d'attente retardée (flush it!) est contre-productive et peut aggraver le problème. Ne videz pas la file d'attente retardée sauf si vous pensez que la majeure partie de son contenu est récemment devenu livrable (c'est à dire par exemple que relayhost est de nouveau disponible après un plantage) !
Notez que bien que le gestionnaire des files d'attente est été redémarré, il peut y avoir des messages dans le répertoire de la file d'attente active, mais la file d'attente active "réelleé en mémoire est vide. Pour rétablir l'état en mémoire, le gestionnaire des files d'attente déplace tous les messages de la file d'attente active dans la file d'attente entrante, puis utilise l'examen normal de la file entrante pour reconstituer la file d'attente active. Le processus de déplacement de tous les messages, de consultation des tables de transport (service de résolution trivial-rewrite(8)), et de ré-importation des messages en mémoire est cher. Évitez donc les redémarrages fréquents du gestionnaire des files d'attente.
Lorsque tous les destinataires livrables d'un message sont livrés et que la livraison a échoué pour une raison temporaire (la livraison est susceptible de réussir plus tard), le message est placé dans la file d'attente retardée.
Le gestionnaire des files d'attente examine la file d'attente retardée periodiquement. L'intervalle d'examen est controllé par le paramètre queue_run_delay. Pendant qu'un examen de la file d'attente retardée est en cours, si un examen de la file d'attente entrante est également en cours (idéalement ils sont brefs tant que la file entrante est petite), le gestionnaire des files d'attente alterne entre le transfert des nouveaux messages entrants et celui des nouveaux messages "retardés". Cette stratégie "round-robin" évite l'encombrement des files d'attentes entrante et retardée.
Chaque examen de la file d'attente retardée ne transfert qu'une partie des messages vers la file d'attente active pour une nouvelle tentative. En effet, chaque message en file d'attente retardée se voit assigné un temps "cool-off" pendant lequel il est reatrdé. Ceci est fait en datant la modification du fichier dans le futur. Le fichier en file d'attente n'est pas éligible pour uen nouvelle tentative avant que cette date soit atteinte.
Ce délai "cool-off" est compris entre $minimal_backoff_time et $maximal_backoff_time. La date de tentative suivante est calculée en doublant l'age du message dans la file d'attente, et ajustée pour s'adapter aux limites. Ceci signifie que les messages jeunes sont initialement représentés plus souvent que les anciens.
Si des sites à grand volume ont couramment de grandes files d'attente retardées, il peut être facile d'ajuster les délais queue_run_delay, minimal_backoff_time et maximal_backoff_time pour fournir des délais assez court au premier échec, avec peut-être des délais plus longs pour les échecs multiples, pour réduire le taux de retransmission des vieux messages et réduire ainsi la quantité de messages précédemment retardés dans la file d'attente active.
Une cause commune des grandes files d'attente retardées est l'échec de validation des destinataires à l'entrée des messages SMTP. Comme les spammers lancent couramment des attaques par dictionnaire depuis des adresses d'expéditions non livrables, les avis de rejets à destination de ces adresses de destination invalides encombrent la file d'attente retardée (et en proportion la file d'attente active). La validation des destinataires est vivement recommandée en utilisant les paramètres local_recipient_maps et relay_recipient_maps.
Lorsqu'une machine avec beaucoup de messages retardés est arrêté longtemps, il est possible que la file d'attente retardée entière retente simultanément la livraison. Ceci peut engorger la file d'attente active. Ce phénomène peut être répété approximativement toutes les maximal_backoff_time secondes si les messages sont de nouveau retardés après une brève période de congestion. Idéalement, un Postfix futur ajoutera un délai supplémentaire aléatoire au délai avant retentative (ou utiliser une combinaison de stratégies) pour réduire les chances de répéter ce phénomène.
Le programme qshape(1) a été développé par Victor Duchovni de Morgan Stanley, qui a également écrit la première version de ce document.
traduction par Xavier Guimard - Retour au menu