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

[David Verdin <adresse@cachée>]

Bonjour à tous,

Le 16/05/12 14:49, Sébastien JEAN a écrit :
> 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).
Sympa réencode tout le message en base 64 avant de le stocker en base de 
données, pour limiter les risques liés aux encodage de chaîne de 
caractère par les SGBD. C'est bien tout le message qui est réencodé, 
entêtes compris. Le passage de 11 à 16 Mo correspond bien au ratio de 30 
% de la base 64.
> Autre question la manière de stocker le mail en base de données, est-elle 
> documentée qque part ?
Non, effectivement ça manque. Il faut que nous l'ajoutions.
> 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).
La table "bulkspool_table" est vidée régulièrement (tous les jours, si 
j'ai bonne mémoire) Sympa supprime les entrées dans cette table qui ne 
correspondent plus à des paquets à expédier dans la table 
"bulkmailer_table".
> 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.
Normalement, tu dois avoir une tâche nommée 
"1338304039.ACTION.purge_tables._global" (l'entier au début aura une 
valeur différente : c'est la data de prochaine exécution). C'est cette 
tâche qui est chargée du nettoyage.

Cordialement,

David Verdin
> 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