Forum TourDeJeu · Règles du forum | Aide Recherche Membres |
Bienvenue invité ( Connexion | Inscription ) | Recevoir à nouveau l'email de validation |
Sybler |
Ecrit le : Lundi 08 Octobre 2007 à 08h58
|
||
Ouf Groupe : Membre Messages : 453 |
Bonjour à tous! J'ai récemment remonté mon serveur en Debian avec MySQL5.0 et je suis un peu embêté par la soudaine chute drastique de performance du serveur MySQL comparativement à avant. En effet, pour le même code, même site, même machine, même db, je passe de page se générant à coup sur en moins de 2 secondes à des temps de génération dépassant les 45 secondes de temps à autre. Et c'est la que c'est gênant: "de temps à autre", car une requête sur 50 ou 100 prendra 100 fois le temps normal. MySQL ne plafonne pas (CPU à 3%), La mémoire est belle (+ de 500 mo de libre) J'aimerais donc savoir si vous avez déjà eu des problèmes ou certaines requêtes, sans raison, s'exécutaient trop lentement ( de 1 à 8 secondes par requête ) alors que normalement, ces requêtes passent en 0.02 secondes ou moins. Si oui, qu'avez-vous fait ? Ceux qui utilisent de grosses tables ( + 500mo ), quelle genre de config utilisez-vous coté my.cnf ? Pour le moment je me suis contenté de booster la mémoire disponible le plus possible ( voir ci-bas ), ce qui semble avoir réduit le problème, mais en aucun cas ne l'a réglé.
Et je n'avais pas besoin de settings aussi abusifs avant pour que tout passe bien. Toute idée est la bienvenue. -------------------- |
||
Haiken |
Ecrit le : Lundi 08 Octobre 2007 à 13h42
|
Ouf Groupe : Membre Messages : 360 |
Les symptômes sont bizarres. Ca pourrait être le disque qui est défectueux, et de temps à autre provoque des IO très longues.
Tu logges les requêtes lentes (slow-query) ? Ca pourrait t'aider à identifier les requêtes sui posent problème. -------------------- Association Nainwak, aide & hébergement des jeux web
Le Blog de l'assoc', encore mieux que l'assoc' tomate ! |
wells |
Ecrit le : Lundi 08 Octobre 2007 à 17h03
|
Pro Groupe : Membre Messages : 143 |
Si se sont toujours les même requêtes qui sont lentes, peu être voir du coté de jointures qui tournent en rond.
Cela expliquerait pourquoi dans certain cas ça marche et d'autres ça met beaucoup de temps. -------------------- |
Sybler |
Ecrit le : Mercredi 10 Octobre 2007 à 05h28
|
Ouf Groupe : Membre Messages : 453 |
J'ai fais une première installation sur un OpenBSD avec le même ancien disque que lorsque ca allait bien. (Qui a pris environ 50h)
Puis j'ai acheté un nouveau disque tout neuf et j'ai remonté tout ca en Debian: même chose. (Qui a pris 4h chrono, lol) Oui, j'ai loggé les slow queries, j'ai même fait mieux: Avant de mettre le site en ligne, j'ai fait affiché chaque requête qui prennait plus de 0.5 seconde à exécuter. J'ai ensuite fait un copier coller d'environ 10 requêtes lente, et j'ai exécuté tout ca d'un coup dans PHPMYADMIN. Et c'était vite comme l'éclair. Chaque requête lente que je test va aller super vite ( < 0.02 sec ). (Cache p-e?) Alors oui, c'est vrai qu'on parle de vieux code pas toujours super optimisé, mais ca explique pas pourquoi les performance varient autant. Si c'est pour être lent, ca devrait toujours l'être ! (Surtout quand on parle de SELECT sur une table simple avec des champs INDEXÉ pour le where...) Nouveauté: J'ai par contre remarqué qu'en ré-important mes tables (En copiant les fichiers directement en fait), la cardinalité sur ma table de 550 mo était de 0. J'ai fais un ANALYSE TABLE et c'est retombé à une valeur de quelque chose comme 75000 ou un truc du genre. Je sais pas encore si ca aidé pour les performances. -------------------- |
butch2k |
Ecrit le : Mercredi 10 Octobre 2007 à 21h08
|
Kid Groupe : Membre Messages : 20 |
T'as vérifié qi il n'y avait pas un problème de table lock et des process en attente ?
Passe tes tables en InnoDB dans ce cas là. De plus j'ai remarqué que certaines de varialbe de conf dépassaient largement les normes acceptées. Pour certaines variables, 32k sont largement plus performant que 16M, c'est bizare mais ça vient de la manière dont ces zones tampons sont utilisés et le temps passé à les parcourir et à les mettre à jour. |
Sybler |
Ecrit le : Mercredi 10 Octobre 2007 à 22h49
|
Ouf Groupe : Membre Messages : 453 |
Salut,
Pourrais-tu me pointer les valeurs précises qui pourraient nuire à la performance ? Comme je l'ai dit dans le premier message, voyant que la config par défaut n'offrait pas les performances attendues, nous avons boosté les valeurs d'à peu près tout. (D'ailleurs MySQL n'utilise toujours pas autant de mémoire qu'il le pourrait. Je trouve ca assez innutile de voir de la RAM innutilisé et des stats qui semblent montrer une assez grosse utilisation du disque dur.) Pour ce qui est des locks, non, rien de problématique de ce coté la à première vue. Et j'ai toujours été en MyISAM, je vois pas pourquoi "soudainement" ca ne fonctionnerait plus. -------------------- |
butch2k |
Ecrit le : Mercredi 10 Octobre 2007 à 23h15
|
Kid Groupe : Membre Messages : 20 |
Le sort_buffer_size et le read_buffer_size doivent être à 128K essaye de reduire de même le myisam_sort_buffer_size et read_rnd_buffer_size.
T'as quoi comme taille de query cache ? Tout est question de dosage, car après tui perds du temps à allouer des blocs mémoire qui ne te servent pas ou bien à tester la vailidité de certaines choses dans tes blocs mémoire (query cache par exemple). T'as beaucoup de connexions simultanée ? Pour moi ton problème peut venir coté MySQL de deux choses, le coté aléatoire pesant fortement dans la balance: soit c'est un process de deadlock de tes threads dû à des table locks, soit c'est un problème d'invalidation d'un cache mais ça me semble déjà plus tiré par les cheveux surtout vu le temps passé. C'est pas plutot un problème avec PHP en fastcgi par hasard ? Genre le nombre de services à expiré et le process fastcgi se termine pour se relancer. |
Sybler |
Ecrit le : Mercredi 10 Octobre 2007 à 23h31
|
||||||||||
Ouf Groupe : Membre Messages : 453 |
# # * Query Cache Configuration # query_cache_limit = 16M query_cache_size = 64M
Depuis 3 jours: max. de connexions simultanées 12 Mais le problème a été constaté lors de test avec aucun accès externe. Donc seulement moi qui refresh une page.
Lorsqu'une page "hang", je fais des SHOW PROCESS, c'est pas super précis, mais ca semble pas venir de la, car oui, ya des lock, mais il reviennent pas d'un SHOW PROCESS a l'autre. Alors qu'une requête qui prend 5 secondes, j'aurais au moins le temps de voir un LOCK 2 ou 3 fois. Connais-tu une facon de sonder cette possibilité plus précisément ?
Qu'est-ce que tu apel "invalidation d'un cache" ?
Pour être honnête, j'ai aucune idée de quoi tu parle (C'est quoi PHP? non, je veux dire: FastCGI ...) Bref, merci pour ton aide, c'est rempli de pistes comme réponse ca -------------------- |
||||||||||
xaero |
Ecrit le : Jeudi 11 Octobre 2007 à 00h11
|
Ouf Groupe : Membre Messages : 593 |
et t'as écarté tout probleme hardware ( ram , disque dur ) ?
-------------------- |
Sybler |
Ecrit le : Jeudi 29 Novembre 2007 à 00h19
|
Ouf Groupe : Membre Messages : 453 |
Hum, en fait tout semble être rentré dans l'ordre... Je ne pourrais pas tellement dire pourquoi par contre ... ( pas que j'ai rien fait et que ce soit miraculeux, mais à force de chercher partout et de faire 2000 trucs, j'ai oublié de tenir ce sujet informé, et du coup j'ai un blanc de mémoire )
-------------------- |