[sympa-fr] can't create new process

[Luc VEILLON <adresse@cachée>]

Bonjour,

Notre moteur de liste (sympa 5.2.3 sur solaris 9)  est mis à genoux et
le processus sympa.pl s'arrête fréquemment ("sympa died") à la suite
d'un problème d'espace :

Nov 25 07:58:19 valinor.orleans.ird.fr sympa[1928]: Can't create new
process in
safefork:
Nov 25 07:58:19 valinor.orleans.ird.fr sympa[1928]: Exiting.

En première analyse, l'origine du problème est une liste qui a été
utilisée dans le cadre d'un appel d'offres, pour recevoir les dossiers
de réponses des candidats : en 24 heures chrono, nous avons absorbé un
demi-giga de messages rien que pour cette liste dont plus de 300 mégas
ont effectivement été validés (la taille maximale des messages supportés
par cette liste est 6 200 000).

Initialement, le file system réservé à / et utilisé pour stocker les
processus (/proc) pouvait être saturé : nous n'avions pas de trace
excepté le message de sympa, mais nous étions suffisamment proches de la
saturation pour qu'une série de messages à traiter à la fois par sympa
et postfix et utilisant plusieurs centaines de méga au total consomment
tout l'espace disque.  Nous avons donc déplacé sympa et ses spool sur un
disque vide de 70 giga.

Les arrêts de sympa se poursuivent quand même.

La mémoire de ce serveur (une sunfire V240) est de 2Go :
Memory size: 2048 Megabytes

Le swap est défini ainsi :
Filesystem           1k-blocks      Used Available Use% Mounted on
swap                    872752        40    872712   1% /var/run
swap                    905104     32392    872712   4% /tmp

On pourrait penser que la taille mémoire est suffisante, bien que la
commande top  affiche une consommation inquiétante du process sympa.pl :
Memory: 2048M real, 554M free, 1968M swap in use, 486M swap free

 PID USERNAME LWP PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
17321 sympa      1  59    0  483M  475M sleep    5:43  0.84% sympa.pl

D'une part, les envois massifs se poursuivent. D'autre part, il est
possible que la liste soit dans un état catastrophique.

Pour le moment, j'ai repéré le digest qui peut poser un problème de
mémoire aux processus :
-rw-r-----    1 sympa    sympa    310306950 nov  23 13:36
adresse@cachée
-rw-r-----    1 sympa    sympa       11167 nov  23 09:25
adresse@cachée
-rw-r-----    1 sympa    sympa       73922 avr  16  2004 ird-tous
-rw-r-----    1 sympa    sympa        4686 nov  24 22:59
adresse@cachée
-rw-r-----    1 sympa    sympa      605656 nov  20 09:00
adresse@cachée
=> je viens de décocher les derniers jours d'envoi de digest qui
restaient actifs
=> je déplace le fichier digest de cette liste en dehors du spool
=> la mémoire consommé par le processys sympa redevient plus rassurante :
  PID USERNAME LWP PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
16573 sympa      1  59    0   78M   68M sleep    0:26  0.01% sympa.pl


Questions :
* le volume du digest peut il expliquer à lui seul le comportement
observé ?
* y a t-il d'autres paramètres sur lesquelles il faut jouer ?

Merci pour vos éclairages

--
     Luc VEILLON              | IRD/Délégation aux systèmes d'information/
     tel.:+33(0)2 38 49 95 95 | Pôle Appui à la recherche/Coordination 
technique
     Fax :+33(0)2 38 49 95 76 | 5, rue du carbone
     adresse@cachée   | 45072 ORLEANS CEDEX 2
     gpg : 0x237A4AD7         | AC signature : http://igc.cru.fr/ac-racine/