[sympa-fr] Souci de gonflement de tables [bdd mysql bulkspool]

[<adresse@cachée>]

J'ai récement été face à un problème "de taille" : le gonflement de la base de données de Sympa.

Je me permet de partager mon expérience pour qu'elle reste dans les archives Web de Sympa.

 

Version de Sympa : 6.0.2

 

le syndrome de départ : augmentation de la taille de la base de données, et surtout, augmentation de la taille du dump journalier, ce qui a fini par saturer notre espace de fichiers.

 

Le souci provenait d'une modification du modèle de tache dans sympa/etc/global_task_models/purge_tables.daily.task que voici :

================================================

title.gettext daily delete unusefull item from any table

 

/ACTION
purge_tables ()
next ([execution_date]+1d, ACTION)

================================================

Cette tâche étant assez longue chez nous (une vingtaine de minute), elle finissait par s'éxécuter en journée.

Nous avons donc modifié l'ordre des 2 dernières étapes pour pallier à ce souci:

================================================

title.gettext daily delete unusefull item from any table

 

/ACTION

next ([execution_date]+1d, ACTION)
purge_tables ()

================================================

Sauf que cela désactive la tâche !

 

Résultat : un gonflement sans fin de la table bulkspool (peut être aussi les autres ...)

Pour voir la taille de vos tables AVANT de faire des modifications, une petite requete SQL bien pratique :

USE information_schema;
SELECT table_name AS "Tables",
ROUND(((data_length + index_length) / 1024 / 1024), 2) "Size in MB"
FROM information_schema.TABLES
WHERE table_schema = "sympa";

 

La procédure qui nous a permis de revenir à la normale, ainsi que d'optimiser un peu les choses :

En italique et entre crochets la ligne de commande rapide (à éditer en fonction de vos chemins d'installation ...)

 

Etape 1 : revenir en arrière sur l'édition du modele de tache  [ vi sympa/etc/global_task_models/purge_tables.daily.task ]

Etape 2 : revenir en arrière sur la tache [ vi $(ls sympa/spool/task/*purge_tables*) ]

Etape 3 : Relancer la tâche de purge :  [ mv $(ls *purge_tables*) $(date +%s).ACTION.purge_tables._global ]

Etape 4 : faire rétrécir la table bulkspool drastiquement : dans votre Editeur SQL : [ OPTIMIZE TABLE bulkspool_table ]

ATTENTION ! cette dernière commande est très lourde, et n'est pas sans conséquence sur votre base; un peu de documentation ici :

http://dev.mysql.com/doc/refman/5.0/fr/optimize-table.html
(merci à David Verdin pour le partage)

 

Nous avons décidé de notre coté de mettre en place une tache cron qui va renommer la tache "***.ACTION.purge_one_time_ticket_table._global" pour forcer son lancement vers midi et minuit chaque jour.

Ainsi qu'une tache de Week End pour optimiser les autres tables.

 

Je laisse le soin aux déevlopeurs de sympa de completer mon mail si besoin.

bon courage à eux.

 

@task_manager :

Pour rappel, cette modification de l'ordre des opérations dans les modèles de tâche est en règle générale à éviter :

Lorsque le task_manager.pl de sympa se retrouve avec 2 taches à faire au même moment :

il traite la première tache, et la reparamètre pour le lendemain au moment de la FIN de l'exécution

il traite la seconde, et fait de même.

le lendemain, les 2 taches ne se présentent plus au même moment, mais avec un delta de temps correspondant à la durée de la première tâche.

ce mode de fonctionnement permet à sympa d'étaler naturellement sa liste de tâches au fil de l'eau sur la journée, pour éviter les pics de charge.

tags de référence : sympa, BDD, bulkspool_table, bulkmailer_table,

 

Manuel OUDIN

Consultant Altran pour Orange

03.90.31.27.08

 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.