[AlternC-dev] Optimisation de MySQL [ WAS gros ralentissement ]

Retour à l'archive de la liste
Le site d'AlternC
Google Custom Search

jerome moinet jerome at mailfr.com
Mar 16 Nov 23:45:47 CET 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hello,

|
| Seul hic, Postfix perdait toute connection avec mysql dans les quelques
| secondes.
|
Que veut tu dire par "perdre toute connection" ? c'est quoi le message
exact dans les logs postfix et mysql ? mysql était planté ? Ca c'est un
truc que je n'ai jamais vu...

positionne log-err = /home/log/mysql.err pour avoir les logs d'erreur mysql.

|
| # Passage à Mysql 4.0.22
|
| OK, seul petit désagrémént l'ensemble des bases sont visibles dans
| phpmyadmin....
|
Il y a une modif à faire au niveau du php.ini, mais je ne m'en souvient
plus. Benjamin, tu t'en souviens ? c'est le truc sur lequel on avait
galéré un moment...


| mysql> status;
| --------------
|
| Threads: 66  Questions: 1278522  Slow queries: 2  Opens: 42837  Flush
| tables: 1  Open tables: 128  Queries per second avg: 7.943
| --------------
|
c'est quoi le "Uptime:" et le "Server version:" dans le status ?

Il y a un prob dans ce status, c'est le "Open tables" à 128, alors que
ton opens est à 42837. et je ne pense pas que ta base tournait depuis
six mois quand tu as fait le status.

Passe le open tables à 4096 et fait la modif de /proc/... qui va bien.
Ca se trouve tu a un max-open tables sur le système qui est très bas et
tout vient de là... met le à 32768.

Autre prob : Threads: 66 avec un Queries per second avg: 7.943. Ca fait
beaucoup de connections pour seulement 7 requêtes à la seconde...

Sur l'autre net net on a ça :
[root at fey mysql]# mysqladmin -u  -p status
Uptime: 232323  Threads: 16  Questions: 16253894  Slow queries: 2
Opens: 132405  Flush tables: 1  Open tables: 4096  Queries per second
avg: 69.962

Ca fait 16 connection pour 69 requêtes/seconde.

fait un "show processlist" pour voir à quoi ressemble tes connections.
Il est très possible que 95% d'entre elles soient en état "Sleep".
Regarde alors leur colonne "time", c'est là-dessus que les variables
wait_timeout et interactive_timeout vont jouer. Ca peut diviser par 10
ton nombre de connections d'utiliser ces variables, et donc
l'utilisation des ressources. 512 Mo de ram pour 7 requêtes/seconde ça
doit tenir.

augmente ensuite ton key_buffer à 128 et trace les logs postfix/mysql
pour voir si la perte de connection est dûe à trop de connections ou
autre. Et si tout marche bien repositionne les variables qui plantaient
(je ne vois pas pourquoi skip-bdb et skip-innodb feraient planter la
connection postfix/mysql, idem pour wait_timeout, interactive_timeout et
record_buffer. Pour query_cache_size elle est tout à fait reconnue).

Désolé de pas pouvoir aider plus,

cdlt,

jerome




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with MultiZilla - http://enigmail.mozdev.org

iD8DBQFBmoLh3ygQTLujCrQRAjy1AJ4tdjSE5W1QdTwPQk+pxH4bdEEfqACeMggQ
fO61vxTvbxd1IDE5bClcSf0=
=Dy7R
-----END PGP SIGNATURE-----



Plus d'informations sur la liste de diffusion Dev