Durées de requêtes mysql différentes en fonction du serveur

Support Debian
#1

Bonjour,

je viens de migrer mon serveur mysql et j’observe de grosses différences de performances sans réussir à les expliquer. Description du cas :

  • cas 1 : vieux serveur - en activité depuis 5 ans, sous mysql 5.5 en debian. J’ai récupéré les tables et les ai transféré sur le nouveau serveur
  • cas 2 : nouveau serveur sous mysql 8, en debian aussi. Le transfert a parfois été un peu compliqué, les tables étant conséquentes.

J’ai noté de forts ralentissement une fois la bascule faite et ai donc effectué des tests. Une requête particulière sur l’ancien serveur va se faire en 0.01080s alors que la même se fera en 3.19905s, ce qui est vraiment beaucoup. J’ai passé toutes les tables à la moulinette vérification/optimisation mais ça n’a rien changé.
Auriez vous des idées ?
De plus, j’ai du mal à modifier les variables de configuration de mysql. En effet, le fichier my.cnf est maintenant vide, je ne trouve pas où l’on pourrait modifier les valeurs de key_buffer ou autre par exemple…
Merci par avance.

Fabien

#2

Bonjour,

Les serveurs disposent exactement du même matériel (CPU/RAM/HDD) ?
Sinon, as-tu pensé à regarder le moteur utilisé sur ton ancien serveur (MyISAM vs InnoDB) ?

#3

Quid de l’optimisation ?

https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl

Voir aussi du côté de percona ils proposent aussi des choses pour améliorer le rendement d’un serveur de base de donnée (même si tout n’est pas forcément compatible).

#4

Bonjour,

merci de vos retours.
Côté conf matérielle, elles n’ont rien à voir : le “vieux” serveur est un serveur virtualisé, avec 4Go de Ram et 4 core d’un Xeon, avec disque en SSD, alors que le nouveau serveur a le Xeon pour lui tout seul, 32Go de RAM et disque en SSD.

Les tables étaient en MyISAM, je suis en train de les passer en InnoDB ; ça réduit l’écart, mais on reste sur un facteur 100.
@Clochette : je ne comprends pas bien le lien…
Merci !

#5

Ca a l’air d’un script perl à executer pour “fine tweaker” les réglages.

#6

Oui, j’ai cherché et trouvé les infos. Cela dit, ça ne donne pas beaucoup plus d’info que le conseiller qu’on peut trouver dans phpmyadmin, mais c’est tout de même intéressant.
Par contre, avez vous des éléments concernant la modification des variables de config, je suis un peu perdu. J’ai l’impression que :

  • je peux rajouter un fichier dans /etc/mysql/conf.d qui s’appellerait toto.cnf (par exemple) et qui contiendrait la ligne (par exemple) key_buffer = 16Mo (mais quid de la bonne syntaxe)
  • ou bien je peux, en commande mysql, faire set persist key_buffer=1610241024;
  • autre possibilité ?

C’est bien cela ? Pas bien clair pour moi…
Encore merci !

#7

Tu peux jouer avec un include afin de disposer de tes modifs ailleurs que sur le fichier de configuration qui sera surement écrasé à la prochaine mise à jour.

Après comme dit plus haut le script te permettra déjà d’optimiser quelque peu ta configuration mais n’étant pas un spécialiset de la DB je te dirai de fouiller aussi du côté de Perconna qui ont un outil pour le tweak plus approfondi.

https://www.percona.com/downloads/percona-toolkit/LATEST/

#8

Bonjour,

Pour la configuration elle doit affectivement se faire dans /etc/mysql/conf.d, dans un nouveau fichier ou dans l’un des fichiers existants.
Il faudra quand me vérifier si ton fichier /etc/mysql/my.cnf n’est pas un lien symbolique et contrôler son contenu, ou celui du fichier vers lequel il pointe, afin de comprendre la gestion des fichiers de configuration.
Pour les directives de configuration, je te recommande té référer à la documentation MySQL. Tu pourras par exemple y voir qu la bonne directive n’est pas key_buffer, mais key_buffer_size et qu’elle ne concerne que le moteur MyISAM. Donc inutile si tu as tout converti en InnoDB.

MySQLTunner est un très bon outil pour trouver les optimisations possibles mais il faut attendre un certain temps d’utilisation de MySQL avant d’avoir des résultats pertinents (24-48h recommandés). Il peut même être utile de relancer l’outil après quelques jours ou semaines.

Une autre chose importante à faire est d’activer la journalisation des requêtes lentes ou slow query log. Cela te permettra de surveiller les requêtes qui consomment beaucoup de ressources, prennent trop de temps, et d’agir en conséquence.

#9

Merci de ces retours.
Concernant l’outil mysqltuner, je l’ai mis, je vais essayer d’en tenir compte pour l’optimisation en laissant le tout tourner quelques temps, après les modifs effectuées.
La conversion des tables est en cour, cela prend un peu de temps (280 tables) car il faut que je reprenne certaines mais ça va se faire, je ne suis pas inquiet.

Par contre, j’ai vraiment du mal avec les paramétrages de mysql. J’ai déposé un fichier perso.cnf dans /etc/mysql/conf.d/, le fichier /etc/mysql/my.cnf ayant la ligne !includedir /etc/mysql/conf.d/ avec le contenu suivant :
key_buffer_size=80M
mais ça n’a rien changé (oui à terme cette variable ne sera plus nécessaire, mais c’est un exemple). En même temps, en écrivant ces lignes, je me dis qu’il faudrait peut être que je rajoute un [mysqld] au début de mon fichier, non ?.. :face_with_raised_eyebrow:

Merci !

#10

Aucune idée, mais vu que ce type d’includedir fait en général un cat des microfichiers pour obtenir un fichier reconstitué, s’il faut [mysqld] dans un my.cnf monolithique, alors dans le cas des fichiers fractionnés, ça me parait raisonnable de supposer qu’on puisse retrouver aussi cette mention de section.
Bon aprés, tu n’es pas en prod, donc ça ne coute rien de tester.

#11

Heuu… ben si c’est en prod ! :sweat_smile:

#12

Encore une fois il faut lire la doc…
Oui, toutes les directives qui concernent la partie serveur doivent être sous la section [mysqld]

#13

J’y passe beaucoup de temps, vraiment, mais je ne trouve pas les choses bien explicites !
Cependant, ça avance !