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

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

denis denis at collectifs.net
Sam 20 Nov 19:54:25 CET 2004


Salut,

En fait tout fonctionne, le problème était ailleurs :-)

Il semble y avoir un problème dans iptables lorsque plusieurs adresses
IP sont sur la même interface et qu'il a une "forte" charge de traffic.

Tout se ralentit assez considérablement, donc lenteur du serveur et 
pertes de connections à Mysql

Ceci était intensifié par les requêtes massives sur un wiki dans le
but d'y inscrire des sites pornos dans les pages referers...

D'ailleurs, pour info, pour arrêter ce genre de spams, il suffit de
mettre un .htaccess à la racine du site avec ceci:

SetEnvIfNoCase Referer
".*(sex|hardcore|mature\-hardy|nude|porn|pussy|xxx|viagra|asian\-4you|shirts\-t\-shirts|capitalraiser|asiantrans|webcam|ficken|fuck|boobs|babes|x\-pictures|macinstruct|incest|linuxwaves|secureroot|gayfunplaces|mygidi|asian\-trans|evenway|carpiar|ixay|i\-ru\.net|xuev|animals\-shirts|striptrend|gay\-|perverted|gayteensites).*" BadReferrer
order deny,allow
deny from env=BadReferrer

Voilà, tout roule.

Pour l'optimisation de Mysql, on vient aussi d'activer d'autres options
de cache, je vous tient au courant de ce que çà donne.

Encore merci et a bientôt 
Denis






Le mar 16/11/2004 à 23:45, jerome moinet a écrit :
> -----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-----
> _______________________________________________
> Dev mailing list
> Dev at alternc.org
> http://alternc.org/cgi-bin/mailman/listinfo/dev




Plus d'informations sur la liste de diffusion Dev