Re: [sympa-fr] Problème de distribution de messages avec des pièces jointes

[Sébastien JEAN <adresse@cachée>]

Pour l'augmentation de la taille de stockage du mail, ce que je comprend est:
-la pièce jointe de 8,3Mo génère un mail de 11Mo suite à l'encodage en base 
16. Jusqu'ici tout va bien. (ratio de 30%, ce qui correspond à peu près à ce 
que l'on attend pour ce type d'encodage)
-son stockage par Sympa pèse 16Mo (mais la pièce jointe est déjà encodé) d'où 
mon interrogation: d'où vient cette nouvelle augmentation de taille.

2 hypothèses peuvent expliquer la deuxième inflation:
-Sympa chiffre le message au moment de le stocker (cf les n-upplet de la 
table « bulkspool_table », « messagekey_bulkspool » et « message_bulkspool ») 
et l'algorithme utilisé serait peut optimum pour la taille des données,
-2ème hypothèse (l'une n'excluant pas l'autre), Sympa rajouterai des données 
lors du stockage du mail en base de données. Sauf qu'ajouter près de 7Mo de 
données complémentaires, cela me parait à minima bizarre… (un des moyens de 
valider cette hypothèse serait de mesurer en fonction de la taille de la 
pièce jointe le ratio d'augmentation entre la taille du mail encodé et son 
enregistrement associé dans la base de données. Si la quantité de données en 
sus entre la taille de l'enregistrement MySql et la taille de la pièce jointe 
est fixe, alors cette hypothèse se tient. A contrario, si l'augmentation de 
la taille est strictement proportionnelle à la taille du mail encode en base 
16, alors c'est l'hypothèse n°1 qui serait à privilégier. Pour l'instant, je 
n'ai pas le test).

Autre question la manière de stocker le mail en base de données, est-elle 
documentée qque part ?

Pour ce qui est de la purge de la table de « bulkspool_table », dois-je 
comprendre qu'une fois le mail distribué l'entrée doit disparaître de la 
table? Si c'est le cas  pour Sympa fonctionnel alors la table devrait être 
quasiment vide… (avec nos 500Mo pour cette table, ce n'est pas le cas).
Je vais surveiller de près l'évolution de la taille de cette table pour 
valider qu'elle ne fait pas qu'augmenter dans le temps.

Merci pour vos remarques.

Sébastien JEAN

---
Sous-direction Infrastructure
Direction du Numérique - Université de Lorraine
Tél : 03.83.59.61.49  06.03.19.73.46


----- Mail original -----
> Bonjour,
> 
> Une piste, les messages sont stockés en base64 pour des raisons
> d'encodage, et le passage en base 64 provoque une augmentation de la
> taille entre 30 et 60% (pas facilement prédictible).
> 
> Par contre la table bulkspool doit se vider, il y a une tache qui
> doit
> s'en occuper lorsque tout les packets correspondants dans la
> bulkmailer
> table ont été traités, il faudrait voir si il n'y a pas un souci avec
> la
> tache en question.
> 
> Cordialement,
> 
> Etienne MELEARD
> SAU - Renater
> 
> 
> Le 16/05/12 13:51, Sébastien JEAN a écrit :
> > Bonjour,
> >
> > Nous rencontrons des problèmes de distribution de mails contenant
> > des pièces jointes (le blocage ne venant ni de la configuration de
> > la liste, ni d'une limitation liée au MTA).
> >
> > Les logs de Sympa indique ceci :
> >
> > May 10 16:37:32 vacherin sympa[1850]: err Bulk::store() Unable to
> > add message in bulkspool_table "INSERT INTO bulkspool_table
> > (messagekey_bulkspool, messageid_bulkspool, message_bulkspool,
> > lock_bulkspool, dkim_d_bulkspool, dkim_i_bulkspool,
> > dkim_selector_bulkspool, dkim_privatekey_bulkspool,
> > dkim_header_list_bulkspool) VALUES ([nos valeurs])"; error : Got a
> > packet bigger than 'max_allowed_packet' bytes
> >
> > La valeur de la variable « max_allowed_packet » étant de 16Mo sur
> > le serveur MySql utilisé par Sympa.
> >
> > Le problème est le suivant : ce message d'erreur (et la non
> > distribution qui en découle) se produit dès qu'un mail dépassent
> > environ 8,5Mo soit une taille près de 50% inférieur à la
> > limitation MySql.
> >
> > J'ai donc fait une petite expérience :
> > -Dump  de la table  « bulkspool_table » (dump1.sql)
> > -J'envoi un mail à une liste de diffusion contenant une pièce
> > jointe de 8.3Mo (mon message est correctement distribué). La
> > taille finale du mail (suite à l'encodage de la pj) est de 11Mo.
> > -Nouveau dump de la table « bulkspool_table » (dump2.sql)
> > -un petit diff : "diff dump1.sql dump2.sql>diff.sql"
> > -le fichier diff.sql (qui ne contient qu'un seul « insert into…»,
> > donc seul mon message a été stocké entre les 2 dump) pèse 16Mo !
> >
> > (pour info, si j'envoi un mail de quelques 100Ko de plus, le
> > message se retrouve bloqué. Cf comportement décrit au début de ce
> > mail)
> >
> > Est-il normal qu'un mail de 11Mo génère une entrée dans la base de
> > données Mysql d'une taille de 16Mo soit une inflation de près de
> > 50% (45% pour être exact) ? De notre point de vue, cela paraît
> > énorme et pas très compréhensible comme fonctionnement…
> >
> > J'en profite pour poser une question à propos de la table «
> > bulkspool_table » qui atteint une taille de 500Mo. Existe une
> > procédure de purge des vieux messages ?
> >
> > En vous remerciant par avance.
> >
> > Sébastien JEAN
> >
> > ---
> > Sous-direction Infrastructure
> > Direction du Numérique - Université de Lorraine
> > Tél : 03.83.59.61.49  06.03.19.73.46
> >
> >
> >
>