Accéder au contenu.
Menu Sympa

fr - Re: [sympa-fr] Optimisation de performance d'envoie.

Objet : Pour les administrateurs de serveurs de listes utilisant le logiciel Sympa

Archives de la liste

Chronologique Discussions  
  • From: Aumont <adresse@cachée>
  • To: adresse@cachée
  • Cc: adresse@cachée
  • Subject: Re: [sympa-fr] Optimisation de performance d'envoie.
  • Date: Tue, 18 Dec 2001 17:20:47 +0100

Bonjour

adresse@cachée wrote:
>
>
> 1 - Malgré le paramètre maxsmtp = 500 il est très rare que le nombre de
> process dépasse 350. Le nombre de process augement trop doucement jusqu'a
> 400
> puis descendre à 34. Je n'arrive pas à trouvé le moyen de garder un nombre
> de
> process élevé avec un BI-PIII 750 avec raid 5 les des deux CPU varie entre
> 0.1%
> et 18%. Il y a t'il un moyen pour augementer le temp de création des process
> sendmail ?.
Oui, il faut empécher sendmail de canoniser les adresses, en effet dans
ce cas l'appel à sendmail est bloquant jusqu'à ce que sendmail obtienne
un éventuel CNAME du DNS pour chacun de ses arguments. C'est seulement à
ce moment là que le process est forké. D'une part cette résolution est
inutile, d'autre part si le dns pédale, c'est la cata coté Sympa qui
arrive à ne plus traiter aucun message alors que la machine est
totalement disponible. Voir FEATURE "nocanonify" (très bien expliqué
page 267 de la éeme edition du O'Reilly sur sendmail).

Nous mettons cette fonctionnalité en place uniquement pour les appels
sortant via sympa en utilisant un sendmail.cf spécifique à sympa. dans
cette configuration, le nombre de sendmail augmente beaucoup plus vite.

Cerise sur le gateau, on peut optimiser certains timer des sessions SMTP
dont les valeurs par defaut colle assez mal avec l'état lamentable de la
disponibilité de certains mailhosts.
En effet ces timers qui s'expriment en minutes voir en 10zaines de
minutes. Il suffit alors d'une douzaines de serveurs saturés parmis vos
gros correspondants pour que les sessions smtp disponibles soit alors
constituées majoritairement (voir exclusivement) de sessions en attente
de réponse du serveur distant. Ces ajustement vise à faire baisser
rapidement le nombre de sendmail en machine pour traiter d'autres
messages. Bien enetendu il faut régler la gestion des spools en
conséquence.

Le timer iconnect est le plus interessant, nous avons positionné :

O Timeout.iconnect=17s
(ne me demandez pas comment je suis arrivé à cette valeur).
>
> 2 - Les adresses en erreur sont à la fois enregister dans la base de
> donnée
> et dans une répertoir définie par le paramètre
> bounce_path /var/sympa/bounce
> sont il utilise avec l'utilisation de la base de donnée ? si oui peut on
> désactivé l'enregistrement de ces adresses.
Oui. Non. Si vous faites tourner bounced.pl les spools ne divergent pas.
Attention dans le cas contraire...

Serge

--
-----------------------------------------------------------
Serge Aumont Comité Réseaux des Universités
Campus Beaulieu
35042 Rennes Cedex



Archives gérées par MHonArc 2.6.19+.

Haut de le page