Attention, c'est justement ce que je
précise dans mon précédent mail.
La tache xxxx.ACTION.purge_tables._global ne fait que vider la
table (tu peux le vérifier en faisant directement une requête sql
sur la table bulkspool, c'est plus facile si tu as un phpmyadmin
installé quelque part pour attaquer la base), mais cela ne rends
pas pour autant l'espace disque déjà utilisé donc ton fichier aura
la même taille.
C'est pour cette raison qu'il a été nécessaire de mettre en place
un script d'optimisation pour cette table bulkspool planifié par
un cron sur nos serveurs.
Cordialement.
Johan GLENAC
DSI
Administrateur Système, Réseaux et Télécom
TROUBIRAN :
Route de Baduel - BP 6011 97306 Cayenne
Tél.
: +594 (0) 594 27 22
08
Fax
: +594 (0) 594 27 22
20
Rectorat - Académie
de la Guyane
www.ac-guyane.fr
|
Le 16/11/2012 07:08, Anne-Lise GROS a écrit :
bonjour,
j'ai donc ajouté une tache xxxx.ACTION.purge_tables._global
dans /home/sympa/spool/task avec le timestamp qui va bien et de
l'autre coté j'ai surveillé dans /var/lib/mysql/sympa la taille
de bulkspool_table. Et bien, la tache n'a rien changé. La table
ne se vide pas, je n'ai rien dans la log de sympa, et
task_manager tourne bien.
Maintenant, je pense que cela peut venir des droits sur la
tache, qui doit être propriétaire et quelles doivent être les
propriétés de la tache ?
merci d'avance
Le 16 nov. 2012 à 10:28, <adresse@cachée>
<adresse@cachée>
a écrit :
Bonjour,
>Cela
libère de l'espace dans la table mais ne règle
pas le pb d'espace disque utilisé dans
/var/lib/mysql/sympa.
Oui en effet, il n'y a pas
que la bulkspool qui est gourmande en espace
disque.
La table logs_table
occupe aussi un espace important (chez moi en ts
cas). Cette table est purgée avec une autre tache
:ACTION.purge_logs_table._global
Cordialement,
Lievre
Marc-Alexandre
MOE Liste de diffusion
Tél
: 03 83 67 51 50
adresse@cachée
De :
adresse@cachée
[mailto:adresse@cachée] De
la part de Johan Glenac
Envoyé : jeudi 15 novembre 2012 21:08
À : 'Anne-Lise GROS'
Cc : adresse@cachée
Objet : [sympa-fr] Fwd: Re: bulkspool_table
et task_manager
Bonjour,
Ci-dessous, un échange que j'ai pu avoir à ce sujet avec
David Verdin.
Je complète un peu la réponse:
- Purge de la table bulkspool_table
Customisation des modèles de tâches.
Copie du répertoire
/home/sympa/default/global_task_models et
list_task_models vers /home/sympa/etc (permet de
conserver la customisation en cas de MAJ de sympa).
Modification du fichier
/home/sympa/etc/global_task_models/purge_tables.daily.task
***************************************************************************
title.gettext delete all 10 minutes unusefull item from
any table bulkspool
/ACTION
purge_tables ()
next ([execution_date]+600sec, ACTION)
***************************************************************************
Reload des process Sympa
Toutes les 10 minutes la table bulkspool_table est purgé
visiblement sans effet sur la charge du serveur et le
fonctionnement de sympa.
Cela libère de l'espace dans la table mais ne règle pas
le pb d'espace disque utilisé dans /var/lib/mysql/sympa.
- Tache planifier de récupération d'espace disque par
optimisation de la table (script bash)
#!/bin/bash
path=/var/lib/mysql/sympa
check_pid=`ls /var/run/mysqld`
user=toto
password=xxxxxxxxxx
bdd=sympa
command_sql="optimize table bulkspool_table"
rapport=/tmp/rapport.txt
taille_bulkspool_table=`du -s $path/bulkspool_table.MYD
| cut -f1`
taille_max=2500000
if [ -n "$check_pid" ]
then
if [ "$taille_bulkspool_table" -gt
$taille_max ]
then
/bin/echo -e "Taille du
fichier $path/bulkspool_table.MYD > à $taille_max Mo
\n" > $rapport
/bin/echo -e
"Optimisation de la table necessaire\n\n" >>
$rapport
/usr/bin/mysql -u"$user"
-p"$password" "$bdd" -e "$command_sql" >> $rapport
OK=`/bin/grep -i "OK"
$rapport`
if [ -n "$OK" ]
then
echo -e
"\nOPTIMISATION OK" >> $rapport
else
echo -e
"\nOPTIMISATION EN ERREUR" >> $rapport
fi
mutt -s "Rapport
nettoyage bulkspool_table SYMPA" -a
/tmp/rapport_bulkspool_table.txt adresse@cachée <
$rapport
else
#echo "Taille du fichier
$path/bulkspool_table.MYD < à $taille_max Mo"
exit 0
fi
else
#echo "Traitement impossible pas de
deamon Mysqld (fichier pid absent)"
exit 0
fi
En espérant que cela puisse vous aider.
Cordialement.
<bannerEmail.png>
Johan
GLENAC
DSI
Administrateur Système, Réseaux et
Télécom
TROUBIRAN
: Route de Baduel - BP 6011
97306 Cayenne
Tél. :
+594 (0)
594 27 22 08
Fax :
+594 (0)
594 27 22 20
Rectorat
- Académie de la Guyane
www.ac-guyane.fr
-------- Message original --------
Sujet:
Re: [sympa-fr] bulkspool_table et
task_manager
Date :
Tue, 06 Dec 2011 14:31:25 +0100
De :
David Verdin <adresse@cachée>
Répondre à :
adresse@cachée,
David Verdin <adresse@cachée>
Pour :
adresse@cachée
Bonjour,
Ça me semble être la bonne approche. L'usage de la
base de données pour la gestion des spools fait que
les tables concernées ont un gros turn over
d'enregistrements. Donc on perd de la place dans les
SGBD qui ne font pas tout seul d'optimisation
régulières.
C'est délicat d'intégrer ce genre de ménage propre à
chaque SGBD dans les tâches de Sympa du fait de la
spécificité de ces SGBD pour les tâches
d'administration. Ton approche avec le cron me semble
donc être la meilleure solution. Peut-être pourrais-tu
montrer le script que tu lances pour effectuer la
commande mysql comme base d'inspiration ?
Merci de tes retours !
David
Le 02/12/11 14:53, Johan Glenac a écrit :
Bonjour,
Après avoir cherché un peu, j'ai procédé de la façon
suivante pour répondre à ma problématique:
- Le process task_manager s'appuie sur des modèles.
Je les ai donc dupliqué (Copie du répertoire
/home/sympa/default/global_task_models et
list_task_models vers /home/sympa/etc) et customizé
le fichier purge_tables.daily.task pour augmenter la
fréquence de nettoyage de la table bulkspool_table.
Néanmoins, l'espace disque physique ne diminue pas
pour autant malgré que la table soit vidée
régulièrement.
- Pour récupérer l'espace disque utilisé par la
table bulkspool_table sur mon système de fichier,
j'ai mis en place un cron qui exécute régulièrement
l'optimisation de la table (commande mysql optimize
table).
Il n'y a "visiblement" pas d'effet de bord négatif
sur le fonctionnement du serveur sympa. Et plus de
gigas à perte et de débordement pour la bdd sympa.
Tous commentaires sur ces pratiques sont les
bienvenus.
<ATT00001.png>
Johan
GLENAC
DSI
Administrateur Système, Réseaux
et Télécom
TROUBIRAN
: Route de Baduel - BP
6011 97306 Cayenne
Tél.
: +594
(0) 594 27 22 08
Fax
: +594
(0) 594 27 22 20
Rectorat
- Académie de la Guyane
www.ac-guyane.fr
Le 29/11/2011 16:38, Johan Glenac a écrit :
Bonjour la liste,
Je travail depuis quelques mois sur sympa 6.1.4 et
j'ai plusieurs questions qui trouveront sans doute
réponses sur la liste (corrigez-moi si je me
trompe):
- Comme je l'avais observé la table
bulkspool_table a tendance à "sévèrement" faire
gonfler la BDD Mysql sympa en fonction du nombre
d'envoi et du poids (pièce jointe) des messages à
distribuer. Cette table bulkspool_table étant
nettoyée par une tâche quotidienne gérée par
task_manager, j'aurais voulu savoir s'il était
possible d'augmenter la fréquence d'exécution de
cette tâche de nettoyage (pour éviter par exemple
la saturation d'un file system dédié à Mysql). Si
oui, comment s'y prendre et y-a-t-il également un
impact sur les performances du serveur?
Sinon quel espace de stockage prévoir pour la BDD
lorsque l'on sait que la plus grosse des listes
(10000 abonnées) pourrait recevoir Xfois un
message de quelques Méga dans la même journée.
Comment avez vous gérer cette problématique?
- Ma BDD sympa étant de type MyISAM, la table
bulkspool_table ayant gonflé (de plusieurs Giga)
n'est plus optimisée lorsque les enregistrements
sont effacés par la tâche quotidienne. Est-il
possible de planifier une optimisation de cette
table avec le task_manager? Si oui, comment? Quel
peut-être les effets de bords et/ou les gains en
performance?
Merci d'avance pour vos réponse.
--
<ATT00002.png>
Johan GLENAC
DSI
Administrateur Système,
Réseaux et Télécom
TROUBIRAN :
Route de Baduel - BP 6011
97306 Cayenne
Tél. : +594 (0) 594 27 22 08
Fax : +594 (0) 594 27 22 20
Rectorat - Académie de
la Guyane
www.ac-guyane.fr
_________________________________________________________________________________________________________________________
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,
France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
|