Problème de performance sur le serveur MySQL de SPIP (1.9.2c)

Arnaud

Février 2010

Bonjour,

Nous rencontrons de grosses difficultés sur le serveur MySQL de SPIP pour la publication d’un Intranet. Les informations sont les suivantes :

Symptômes :
– Le site Intranet n’est plus accessible (timeout au niveau du navigateur).
– Tous les threads apaches sont occupés (en attente de réponse SQL).
– Le serveur MySQL est à 100% de consommation CPU sur les 8 coeurs.
En analysant les journaux de logs MySQL, on s’apperçoit qu’il y a énormément de requêtes de mise à jour : 2 300 000 requêtes (update, delete, create) pour une période de 60 heures (soit 43 000 requêtes de modification / heure).
Une analyse plus précise fait ressortir la requête suivante comme la grande gagnante avec 1 700 000 apparitions :
UPDATE spip_diplonet.spip_rubriques
SET statut_tmp=’publie’, date_tmp=’2009-06-03 10:27:26’
WHERE id_rubrique=x ;

Les questions sont les suivantes :
– Est-il normal qu’il y ait autant de requêtes de mise à jour sur la base ?
– Et est-il normal qu’il y ait autant de requêtes de mise à jour sur les rubriques ?
– Y a-t-il un moyen de limiter le nombre de requêtes SQL ?

Volumétrie :
– 15 000 articles
– 20 000 pages
– 26 000 documents
– 1500 rubriques

– 15 000 utilisateurs potentiels / 1000 à 1500 utilisateurs simultanés
– 20 nouveaux articles publiés / jour

Architecture basée sur 2 serveurs :
– un serveur (2 processeurs dual core + 4Go de RAM) Apache (2.2.3-4+etch11) + php (5.2.0+dfsg-8+etch16) + SPIP (1.9.2c) sur Debian Etch
– un serveur (4 processeurs dual core + 4Go de RAM) avec MySQL (5.0.32-7etch11) sur Debian Etch

Configuration :
– $derniere_modif_invalide = false ;
– durée de validité du cache à 5 minutes sur la page d’accueil et 2h sur les autres pages
– niveau d’isolation des transactions MySQL par défaut : REPEATABLE-READ

Plugins utilisés :
– Lecteur Multimédia en Flash (MP3,flv)
– Acces Restreint 2.0
– Couteau Suisse
– Diapo
– Imprimer document
– Menus deroulants
– Thickbox v2
– Nombres de visiteurs connectés

D’avance, merci pour vos réponses.

Arnaud.

Base de données MySQL SPIP 1.9

Par note Par date Par date chronologique

Indiquez l’intérêt que vous portez à cette réponse

0

Cédric

Février 2010

Bonjour,
la requête incriminée concernant l’update de statut_tmp sur spip_rubriques n’intervient que lors de la publication/dépublication de contenu. Même en cas de mauvais optimisation elle ne devrait intervenir au pire que 1500rubriques*20articles publies/j soit 30000/j.

Les autres requêtes insert/delete concernent sûrement la gestion des invalideurs de cache, ce qui paraît logique avec une durée de cache de 2h : chaque mise à jour de cache provoque une suppression/insertion en base.

La gestion du cache de SPIP 2.0 serait sûrement plus adaptée dans ton cas (elle ne repose pas sur des invalideurs en base, et évite toutes les transactions de gestion du cache)
Pour info, $derniere_modif_invalide n’a aucun effet en SPIP 1.9.2, sauf si tu as une version du cache inspirée de SPIP 2.0.

Pour une réponse plus précise, une analyse circonstancié du site s’impose afin de déterminer les meilleures stratégies à mettre en œuvre.
Indiquez l’intérêt que vous portez à cette réponse

0

equipement

Février 2010

Bonjour,

Les requêtes en question (update de statut_tmp sur spip_rubriques) sont émises par la fonction de recalcul des rubriques.

Cette fonction comprend plusieurs boucles. En générant une trace spécifique, il apparaît que sur un site avec 1830 rubriques, cette fonction génère environ 1400 requêtes mysql (update de statut_tmp sur spip_rubriques), soit moins que le nombre total de rubriques.

La fonction de recalcul des rubriques est déclenchée dans les cas suivants :

– on modifie une rubrique (le fait de cliquer sur le bouton "Enregistrer" suffit à déclencher le recalcul)
– on publie un article
– on dépublie un article
– on renseigne le titre d’une pièce jointe
– en tâche de fond (au plus une fois par heure)
– on change la date de mise en ligne d’une pièce jointe
– on ajoute une pièce jointe dans une rubrique
– on supprime une pièce jointe dans une rubrique
– on déplace un article publié,
– on renseigne ou modifie la date de rédaction antérieure de l’article
– on crée une rubrique
– on supprime une rubrique
– etc.

Aussi, il est préférable de limiter le nombre de rubriques et de placer les informations dans les articles (et pas dans les rubriques).
Indiquez l’intérêt que vous portez à cette réponse

0

equipement

Février 2010

Comme la question porte sur SPIP 1.9.2c, ma réponse du 10 février à 15h44 porte sur SPIP 1.9.2c.

Aussi, il convient de souligner que, pour SPIP 2.0.10, la réponse serait différente.
Indiquez l’intérêt que vous portez à cette réponse

0

$quirrel

Février 2010

Salut,

Pourquoi ne pas utiliser un cache plus long #CACHE24*3600 dans votre fichier rubrique.html ?

squirrel
Indiquez l’intérêt que vous portez à cette réponse

0

Arnaud

Février 2010

Merci pour vos réponses, à l’étude.
Le cache #CACHE24*3600 serait une bonne chose, mais quand une information doit être publiée, elle doit être instantanément visible par les intranautes sans quoi on se fait taper sur les doigts : avec une telle valeur, ce ne serait pas possible. Le recalcul manuel d’une page par le lien "Recalculer cette page" ne met pas à jour le cache ; la page à jour est visible par les personnes loguées sur SPIP mais pas par le reste des intranautes. On cherche également à savoir pourquoi. Par conséquent, on a une valeur #CACHE 300 pour le squelette rubrique.html.

Merci encore.

Arnaud.
Indiquez l’intérêt que vous portez à cette réponse

0

$quirrel

Février 2010

Bon, mettez au moins toutes les heures, comme le /squelettes-dist/rubrique.html par défaut de SPIP ! Par ce que toutes les 300 secondes, c’est court quand même !

#CACHE{3600}

squirrel
Indiquez l’intérêt que vous portez à cette réponse

0

Arnaud

Février 2010

Merci.
Si je mets toutes les heures, une mise à jour de la rubrique s’affichera =au mieux= une heure après qu’elle ait été faite : c’est beaucoup trop long pour notre hiérarchie qui veut de l’immédiateté. Mais je vais tout de même changer le paramètre et le repasser à 3600 secondes. On avisera lors d’une mise à jour sensible...

Arnaud.
Indiquez l’intérêt que vous portez à cette réponse

0

$quirrel

Février 2010

Si non tu peux aller voir cet article très interéssant sur les caches de Spip ! Tu devrais trouver ton bonheur !

programmer.spip.org/Cache-des-pages

squirrel
Indiquez l’intérêt que vous portez à cette réponse

0
$quirrel

Février 2010
Avec le fichier mes_options.php à mettre dans le dossier /config

// Invalider les caches a chaque modification du contenu ?
// Si votre site a des problemes de performance face a une charge tres elevee,
// vous pouvez mettre cette globale a false (dans mes_options).
<?php $derniere_modif_invalide = false; ?>
squirrel
Indiquez l’intérêt que vous portez à cette réponse

0

Cédric

Février 2010

@squirrel : si tu avais pris le temps de lire le thread, tu aurais vu que j’ai déjà dit

Pour info, $derniere_modif_invalide n’a aucun effet en SPIP 1.9.2
Indiquez l’intérêt que vous portez à cette réponse

0

$quirrel

Février 2010

Huumm, çà m’apprendra à lire en diagonale !

squirrel