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

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

Bonjour,

Merci pour cette réponse même si je n'ai pas compris l'intéret du ré-encodage 
en base 64 pour l'insertion en base de données.

Je me permet de faire remarquer qu'il serait intéressant de compléter la 
documentation pour indiquer que la taille max des pièces jointes que l'on 
peut envoyer à une liste dépend de la valeur « max_allowed_pacquet » du mysql 
qui doit être environ 2 fois la valeur max autorisée dans son MTA (« 
message_size_limit » pour un postfix).

Bonne réception

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 à 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
> >>>
> >>>
> >>>
>