Re: [sympa-fr] multiples sympa.pl tournant en parallele ?

[Aumont - Comite Reseaux des Universites <adresse@cachée>]

Bonjour
>
> J'ai 2 groupes de mailing-list: l'un regroupe des newsletter (peu
> d'envoi mais à un grand groupe de personnes) et l'autre des mailing-list
> avec des envois tres regulier à peu de personnes.
>
> J'ai l'impression que sympa.pl (3.3.5) traite un message après l'autre.
> Ce qui fait que lors de l'envoi d'une newsletter, tous les autres
> messages sont en attente, parfois pendant plusieurs heures.
Un bon réglage de Sympa sur une machine même peu puissante doit
permettre de traiter l'envoi dans une liste de +sieurs 10zaines
de milliers d'abonnés en quelques minutes. A cet effet, il faut
optimiser les processus sendmail : feature nocanonify, réglage
des timers (iconnect), augmentation du facteur de groupage de sympa
(nrcpt). et augmentation du nombre possible de sendmail en parallèle
(maxsmtp), parfois en optimisant des paramêtres du système pour
contourner des butées système tel que "too many open file ou too
many processus. Avec cela on arrivait à 20000 destinataires en 6 minutes
sur un Bi-Pentium 450Mz + 512 mega de ram.

Au dela de ces optimisations, le pb que vous soulevez peut perdurer,
même nettement moindre. On peut alors faire tourner +sieurs sympa en
parallèle, mais ils ne doivent pas paratager le même spool. Il faut
alors compiler deux fois sympa essentiellement pour obtenir deux pgm
queue qui utilisent deux sympa.conf disjoints. Les deux sympa.conf ne
diffèrent que par le path des spool. Via les alias on envoie répartis
alors les messages dans les deux spools et bien entendu on lance 2
processus Sympa.pl. En gros, on a fait deux installations de sympa
mais on ne montre qu'un service de liste.

Autre solution : patcher Sympa.pl pour qu'il renomme les fichiers au
début du traitement et ignore les fichiers en cours de traitement par
un autre processus. Normalement on peut alors lancer autant de processus
sympa que souhaité. Ci dessous ce patch pour le spool principale, il faut
appliquer le même patch pour le spool digest et enfin contourner le test
sur sympa.pid. Ne pas oublier de valider ces modifs et de nous les
retourner :-)

*** sympa.pl.~1.104.~   Mon Sep 23 15:13:13 2002
--- sympa.pl    Tue Sep 24 08:58:22 2002
***************
*** 412,417 ****
--- 412,418 ----
        next if ($t_filename =~ /^T\./);

        ($t_listname, $t_robot) = split(/\@/,$1);
+
        
        $t_listname = lc($t_listname);
        if ($t_robot) {
***************
*** 420,425 ****
--- 421,433 ----
            $t_robot = lc($Conf{'host'});
        }

+       ## Skip files currently processed by some other process (R.xxx)
+       next if ($t_filename =~ /^R\./);
+
+         if (rename "$Conf{'queue'}/$t_filename", 
"$Conf{'queue'}/R.$t_filename") {
+           $t_filename = "R.$t_filename";
+       }
+
        my $list_check_regexp = 
&Conf::get_robot_conf($robot,'list_check_regexp');

        if ($t_listname =~ /^(\S+)-($list_check_regexp)$/) {