Performances Postfix

Exécuter postfix sur ubuntu, en envoyant beaucoup de courrier (~ 1 million de messages) par jour. les charges sont extrêmement élevées mais pas beaucoup en termes de charge CPU et mémoire. N'importe qui dans une situation similaire et sait comment supprimer le goulot d'étranglement?

Tout le courrier sur ce serveur est sortant.

Je devrais supposer que le goulot d'étranglement est le disque.

Juste une mise à jour, voici à quoi ressemble iostat:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.12   99.88    0.00    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00    12.38    0.00    2.48     0.00   118.81    48.00     0.00    0.00   0.00   0.00
sdb               1.49    22.28   72.28   42.57   629.70  1041.58    14.55   135.56  834.31   8.71 100.00

Ces chiffres correspondent-ils aux performances que vous attendez d'un seul disque?

sdb est dédié à postfix.

Je pense que c'est un shuffling de file d'attente, de entrant-> actif-> différé

Plus de détails sur les questions:

Serveur: Processeur quad core Xeon (R) E5405 @ 2.00GH avec 4 Go de RAM

Moyenne de charge: 464,88, 489,11, 483,91, 4 cœurs. mais l'utilisation de la mémoire et du processeur est minime

Instances de suffixe entre 16 et 32

Cela peut sembler un peu fou, mais vous devez:

1. Réduisez la journalisation au strict minimum dont vous avez besoin. Faites syslog uniquement log mail.err ou supérieur.
2. Ajoutez plus de RAM. Oui, Postfix n'en a pas besoin, mais une RAM supplémentaire signifie un cache de page supplémentaire pour le noyau.
3. Vous n'avez pas mentionné le système de fichiers sur / dev / sdb (ce qui compte aussi), mais passez-le définitivement noatime, ce qui devrait réduire la charge au moins un peu.
4. Voyez la taille de votre / var / spool / postfix. Si c'est sous un couple, envisagez de le déplacer vers un disque virtuel.

Je ne suis pas d'accord avec ceux qui ont suggéré d'utiliser un disque RAM pour "/ var / spool / postfix". Cela signifie que l'intégralité de votre file d'attente de messagerie sera stockée dans la RAM. Si votre serveur tombe en panne ou perd de son alimentation, les messages dans la file d'attente sont définitivement perdus. C'est vraiment mauvais du point de vue client / utilisateur car le message a déjà été accepté avec succès pour la livraison. Pire encore, votre serveur n'enverra pas d'avis indiquant qu'un e-mail a rebondi ou n'a pas pu être remis car la file d'attente sera vide lorsque le serveur reviendra.

Au lieu de cela, j'ajouterais autant de disques rapides que vous le pouvez; Je ne peux pas vraiment estimer le nombre dont vous aurez besoin avec les informations fournies. D'après la sortie "iostat" ci-dessus, il semble que vous fassiez ~ 120 IOPS à "sdb" (somme de r / s et w / s). Vous pouvez raisonnablement estimer qu'un seul disque SCSI ou FC à 15 000 tr / min peut gérer 150 IOPS. Je commencerais avec 5 disques SCSI à 15 000 tr / min et un contrôleur RAID décent. Configurez-le en RAID-10 sur 4 disques avec 1 disque de secours. Je ne suis pas sûr que cela résoudra complètement votre problème, mais cela ne le rendra certainement pas pire.

Exécutez postfix sous un profileur (gprof?), Ou regardez dans les journaux. Postfix enregistre de nombreuses informations de synchronisation qui pourraient vous indiquer où se trouve le blocage. Les endroits communs à regarder sont:

1. Performances du disque. Il pourrait être temps pour RAID-10 pour votre file d'attente.
2. Tout type d'E / S réseau sur les messages. Listes noires DNS? SAV?
3. Milters et autres filtres que vous avez installés.
4. Les recherches d'authentification et d'UID se font sur le réseau ou sur un processus (ldap, sql).
5. ne pas utiliser de proxy: pour les cartes lentes (comme ci-dessus)

Un million de messages par jour est d'environ 11 par seconde, en supposant que le débit est constant. Postfix devrait à lui seul être capable de gérer au moins un ordre de grandeur supérieur à celui du matériel serveur d'entrée de gamme. Je suppose donc que vous avez plus qu'un simple suffixe en cours d'exécution, ou des pics de débit très inégalement répartis.

Votre situation ressemble certainement à un serveur fortement lié aux E / S. Cela est normal avec un MTA, qui doit effectuer de nombreuses petites écritures pour garantir qu'il ne perdra pas de courrier.

Prenez le temps de régler les E / S sur /var/spool/postfixet /var/log. La meilleure pratique pour les serveurs postfix occupés est de séparer les deux sur des broches différentes et de s'assurer que la journalisation asynchrone est activée. préfixez le nom du fichier journal de votre journal de messagerie avec un tiret sous Linux.

mail.info                              -/var/log/mail.log

ou similaire.

Si vous utilisez amavisd-new, assurez-vous que sa zone de travail se trouve sur un système de fichiers tmpfs. Nous le mettons habituellement /tmp/vscan/. Ceci est sûr, car amavisd-new ne renvoie pas de réponse de fin de données tant que le tronçon aval (post-filtre) n'a pas accepté le message.

Certaines personnes recommandent noatimedes options de montage pour le spool postfix. C'est potentiellement imprudent, en raison de la façon dont postfixe dépend de la sémantique du système de fichiers. Voir par exemple http://archives.neohapsis.com/archives/postfix/2006-01/1916.html .

Il semble que votre sous-système de disque devrait au moins être considéré comme faisant partie du problème. En raison de la façon dont postfixe mélange les fichiers autour de / var, je suggère de googler pour "modifier le système de fichiers ext3" (au moins définir noatime et writeback) pour voir si vous ne pouvez pas augmenter les performances au niveau du système de fichiers.

J'ai deux grappes de serveurs qui doublent le DNS et le SMTP sortant pour les courriers électroniques destinés au client et exécutent 250 000 messages par jour (2 000 à 10 000 / heure) sans nulle part près de ce type de liaison d'E / S.

Ressemble à un goulot d'étranglement pour le stockage.

L'iowait de 99,88 vous indique que votre système passe beaucoup de temps à attendre votre stockage.

Je suis d'accord avec Bill Weiss. Vous devriez regarder dans une configuration raid10 pour la file d'attente.

ou commencer par

vmstat 1

"iostat 1" suggéré par moshen est également bon

à partir de vos statistiques, un sous-système de disque plus rapide serait bien. raid-10 sur 6-8 disques 15k rpm peut-être avec un peu de cache, quelques concerts de mémoire à bord.

montez votre répertoire spool avec les options noatime, nodiratime. pensez à régler ou à modifier votre système de fichiers pour gérer de nombreux petits fichiers [je suppose].

Brian

Vous devez vraiment obtenir un disque plus rapide, ou de préférence passer à une solution de raid. De quel type de serveur s'agit-il?

James

Si vous exécutez amavis pour filtrer le spam et les virus, vous devez augmenter le nombre de processus amavis simultanés. Selon votre configuration, vous devrez peut-être augmenter à la fois le nombre de processus smtp-amavis de postfix master.cf, ainsi que le paramètre approprié dans amavis.conf.

Combien de cœurs dans la boîte et quelle est la charge réelle? Quel est le taux réel d'envoi des messages?

Comme la plupart, ma première pensée est le disque, alors vérifiez ça.

Cependant, l'utilisation du réseau peut en être la cause, tout comme une charge d'interruption élevée (mauvaise carte?), Alors vérifiez-les. J'ai trouvé que même pour un serveur de messagerie modeste, avoir un serveur DNS à mise en cache rapide (je suis partiel à "non lié") sur la même boîte aide à réduire la latence et la charge du réseau.

avec vous faisant 630 lectures et 1042 écritures par seconde, je suggère vraiment d'augmenter votre mémoire dans le système (pour mieux gérer le système d'exploitation et un lecteur RAM), puis de faire de votre dossier postfix un ramdisk.

Je suggérerais également de placer vos journaux de messagerie sur leur propre partition sinon sur leur propre disque.

Ce n'est pas un problème d'E / S, c'est un problème de configuration postfix. Vous lui demandez d'en faire trop à la fois et de vous créer un goulot d'étranglement. Consultez le fichier lisez-moi d'optimisation des performances de postfix et / ou publiez votre fichier main.cf afin que nous puissions vous aider.

on dirait que vous avez un disque douteux. Votre serveur ne fait que 72 requêtes de lecture / sec et 42 écrit / seconde. Mon disque dur de bureau Seagate 7200 tr / min peut faire plus de 100 demandes de lecture / écriture aléatoires par seconde et y faire face.

Essayez de monter la bobine sur sda et voyez si la charge s'améliore.

Mais avant de dépenser plus d'argent sur le disque, procédez comme suit:

1. Exécutez qshape actif, qshape différé et qshape entrant et indiquez-nous le total de chaque commande.

   Un nombre inhabituellement élevé de messages dans la file d'attente différée signifie que votre serveur de messagerie peut être utilisé par des spammeurs pour relayer leurs spams (par exemple, envoyer des e-mails vers un domaine inexistant, ce qui entraînera une nouvelle tentative de postfix).

2. Assurez-vous que votre serveur de messagerie n'est pas sur liste noire ( http://www.mxtoolbox.com/blacklists.aspx )

3. Vérifiez le temps de réponse DNS et exécutez un cache DNS local.

   Le serveur de messagerie utilise assez largement le DNS. Do dig somedomain.com mx Run il sur quelques hôtes des différents. En général, le temps de réponse doit être inférieur à 100 - 400 ms. Si vous obtenez une réponse plus élevée, votre DNS peut ne pas fonctionner correctement. Essayez différents DNS (vous pouvez essayer Google 8.8.8.8 ou OpenDNS: 208.67.222.222)

4. Vérifiez votre réseau. (par exemple ifconfig) et voyez combien de paquets d'erreur. Vérifiez si votre lien est saturé ou façonné. Vérifiez s'il y a eu un nombre élevé d'opérations d'expiration dans les journaux de messagerie. Faites tcpdump et assurez-vous que les paquets ne sont pas perdus ou retransmis.

5. Pouvez-vous nous dire si la console est réactive (par exemple lorsque vous tapez une commande à quelle vitesse le système vous donne-t-il des commentaires)?

   Généralement, un problème de réseau (par exemple DNS) fera monter la charge en flèche, mais le système est toujours réactif.