Salut !

Mon MySql est extrèmement sensible aux petites surcharges du système et aux requetes faites la meme seconde.
J'ai équipé mes cgi (perl) de chronometres et peux ainsi tracer le temps moyen en ms et voir quelle partie du code est longue.
Quand tout se passe bien, le cgi au complet s'execute en 120ms - Et lorsque 5 requetes tombent la meme seconde, ca pousse parfois le tout à 4 secondes et plus ! et ce sont les requetes sql qui sont longues à ce moment.
Ce site par exemple, a 5000 visiteurs par jour et je dois avouer qu'il est très équipé en sql. (il y a 1 ou 2 tables de 200000 lignes mais 50MB chacune env)

=== SERVEUR : ===

=== MY.CNF : ===

+ relay config...
parce que j'ai répliqué sur un slave server-id=2 avec basse priorité et petite mémoire juste pour mysqldump

Le master est nice -7 ; slave est nice 8
Apache est nice -8

=== MY SQL STATISTICS GRAPH : ===

Comme vous pouvez le voir :
- mon disque est tres peu utilisé (moins de 1 pour 1000)
- mon cache est très utile: 15 à 20% des requetes viennent du cache et il n'est pas plein
- j'ai 1 connexion par /s et 10 queries /s
 
- dans la courbe du 2010-09-11 on voit parfois jusqu'a une somme de 60 secondes de slow queries, par minute. (somme des queries plus longues que 0.5s) ce sont les petites surcharges du serveur qui me poussent parfois la moyenne des cgi à pres de 7s !

Alors comment pourrais-je etre sur que MySql réponde toujours dans un temps raisonnable ?
Est-ce que je devrais prioriser MySql plus que apache ?
Je ne vois pas trop comment donner plus de pouvoir à MySql sachant que son cache n'est pas plein et que tous les .MYI rentrent dans key_buffer_size.
Merci beaucoup par avance pour vos idées !

passe un coup de http://blog.mysqltuner.com/ pour voir ce qu'il te dit

 
query_cache_limit : inutile de la baisser puisque mon cache n'est pas utilisé en plein.
 
OPTIMIZE TABLE : je viens de faire ca sur mes tables les plus grosses.
Tout d'abord, ca m'a crashé une table ! que j'ai vite réparée avec myisamchk.
Et ensuite, j'ai l'impression que beaucoup de choses sont plus rapides, mais j'ai besoin de plus de recule pour voir l'impact que ca a.

Si tu lances les queries a la main est-ce que tu as le meme probleme?
C'est juste pour etre sur que le probleme est uniquement lié a MySQL et pas une combinaison de choses.
 
Si tu fais le meme tests sur des tables qui ont 2x moins d'enregistrements, ca va 2x plus vite ou pas?
 
On dirais que soit tous les CPU ne sont pas utilisés (peu probable, sinon tu aurais le probleme aussi apres un restart) ou que tes indexes ne sont pas maintenus (reindex/rebuild).

Par contre note bien que tes 8 GB de ram ne servent à rien si tu as un kernel 32 bits comme c'est marqué dans le rapport.

Tout d'abord, merci à tous pour votre aide.
 

 
Justement, cette question est très intéressante car j'ai l'impression que la somme des slow queries ne correspond pas du tout à la somme des moyennes de mes sites.
Je veux dire que (lorsque ca se passe mal) les lignes de code perl concernant sql sont largement plus lentes que le temps des requetes.
Pourtant, chacune de ces parties chronométrées n'incluent qu'une requete sql, meme pas sa connection, qui n'est pas généralement ce qui prend du temps (en socket d'ailleurs)
Par ex: une requete sql dans le perl semble prendre 4s en cas de crise, mais ca devrait me faire beaucoup plus que 60s de slow queries cummulées par minutes (voir mon graph) car j'ai alors bien plus de 15 requetes lentes comme ceci dans une minute. (sachant en plus que les slow queries ne sont que >0.5s)
Après, je ne suis par certain de ca, mais j'en ai bien l'impression.
 
Oui, des petites tables c'est rapide, aucun doute.
(reindex/rebuild) -> hum, je vais checker ce que c'est, je ne connais pas !
 

 
Oui, j'ai bien vu merci.
Mais pour mon sql 3.5 me suffisent largement il me semble, et j'utilise énormément de tmpfs et ramfs a coté. Donc les 8GB sont pratiquement utilisés à 100%