Forum Programmation.SQL Optimisation MySQL : fail

Posté par . Licence CC by-sa
Tags :
4
20
mai
2017

Bonjour, j'ai eu l'idée saugrenue de vouloir optimiser mon serveur MySQL (5.5, Debian) vu que je suis passé de 32G à 64G de RAM.
Visiblement ce fut une très mauvaise idée car depuis mes requêtes sont horriblement lentes (CPU à 100%) et restaurer le my.cnf dans son état d'origine n'a rien changé ! Ni même rebooter le serveur (oui j'ai vraiment tout essayé …) Du coup je ne comprends pas.

Concrètement j'ai 2 bases, une Innodb d'environ 400Mo et une MyISAM d'environ 1.5Go. J'ai joué avec les variables suivantes (avant il y avait juste les valeurs par défaut):

slow_query_log=1
slow_query_log_file=/var/log/mysql/mysql-slow.log
long_query_time = 2
innodb_buffer_pool_size=4G
tmp_table_size = 256M
max_heap_table_size = 256M
join_buffer_size = 32M
query_cache_limit       = 10M
query_cache_size        = 100M
key_buffer_size         = 256M

Ensuite j'ai redémarré le service et pendant les premières heures tout allait bien. Puis les performances se sont rapidement dégradées alors que le serveur ne swap pas ! J'ai pu constater que c'était le CPU qui limitait certaines (grosses) requêtes : ces dernières prenaient 2s avant "optimisation", elles prennent maintenant quasiment 1 minute. Même après avoir restauré le fichier de conf dans son état d'origine.

Précisions :
- Certaines requêtes font des jointures entre les deux bases
- les requêtes qui n'utilisent que la base innodb sont aussi touchées (base Redmine, avant elles n'avaient aucun soucis)
- mysqlcheck me donne "OK" partout
- les recommandations de mysqltuner n'ont rien changé

Voilà, si quelqu'un a une idée … Je vous remercie d'avance.

  • # Virer la RAM ?

    Posté par . Évalué à 1.

    Salut,
    Je n'y connais rien du tout à MySQL mais, personnellement, dans ce genre de cas, outre la remise en état de la configuration logicielle que tu as déjà effectuée, je remettrai aussi la config matérielle dans son état initial, juste pour voir. Donc j'enlèverais les 32 GiB de RAM supplémentaires.

    • [^] # Re: Virer la RAM ?

      Posté par . Évalué à 1.

      Peut-être que les barettes ne sont pas à la même fréquence, ça pourrait éventuellement expliquer une baisse de perf dû à du matériel.

      Ou tout simplement défectueuse.

      • [^] # Re: Virer la RAM ?

        Posté par . Évalué à 2.

        Bonjour et merce pour votre réponse. Ce sont des serveurs dédiés. J'ai changé de serveur en fait, pas juste rajouté de la RAM. Et avant mes modifications de config, tout fonctionnait correctement dc je ne pense pas que le serveur soit en cause.

        • [^] # Re: Virer la RAM ?

          Posté par . Évalué à 2.

          Dans ce cas il ne te reste plus qu’à répondre au collègue suggérant d’effectuer un EXPLAIN sur les requêtes lentes.

        • [^] # Re: Virer la RAM ?

          Posté par . Évalué à 3.

          alors que le serveur ne swap pas ! J'ai pu constater que c'était le CPU qui limitait certaines (grosses) requêtes : ces dernières prenaient 2s avant "optimisation", elles prennent maintenant quasiment 1 minute.

          Ce sont des serveurs dédiés. J'ai changé de serveur en fait,

          donc tu as changé de hardware, de disque dur, de CPU…
          le CPU precedent etait peut-etre plus veloce, ou ton disque dur plus rapide

          quand tu fais un top
          et que tu affiches le detail (shift+1) tu voit des %wai ?

          • [^] # Re: Virer la RAM ?

            Posté par . Évalué à 2. Dernière modification le 22/05/17 à 16:55.

            Le changement de serveur date de plusieurs mois, ces lenteurs datent précisément du lendemain de mes modifs du fichier de conf (il y a environ 1 semaine) du coup je ne suis pas sûr que le hardware soit fautif.

            Par contre j'ai bien des 0.X wa sur certains coeurs (il y en a 8) et j'ai pu en voir un à 10. La doc dit

            wa  --  iowait
              Amount of time the CPU has been waiting for I/O to complete.

            C'est grave docteur ? Ça veut dire que le CPU attend le disque, donc que je n'ai pas assez de données en cache ou j'ai tout faux ?

            • [^] # Re: Virer la RAM ?

              Posté par . Évalué à 4.

              c'est à peu pres ca.
              il y a un truc qui fait travailler le disque,

              peut-etre le gros innodb, qui ne reduit jamais,

              tu dois pouvoir creuser avec iotop qui va te dire qui fait le plus d'I/O sur la machine

  • # Explain

    Posté par (page perso) . Évalué à 5. Dernière modification le 21/05/17 à 09:34.

    Si Tu fais un explain sir cette requête, tu vois bien qu'il utilise les index comme il faut?

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Explain

      Posté par . Évalué à 2.

      Bonjour, j'ai pu en améliorer certaines (il me manquait un index). Mais le problème principal se trouve au niveau de l'instance Redmine. Là toutes les requêtes utilisent les index (ce sont les requêtes/index d'origine du bugtracker) mais j'ai qd même des temps de réponse de plusieurs secondes sur les recherches.

  • # slow_query_log

    Posté par . Évalué à 2.

    tu as essayé en désactivant slow_query_log?

    • [^] # Re: slow_query_log

      Posté par . Évalué à 2.

      Bonjour, oui. J'ai essayé avec, avec "=0", et sans (comme dans le fichier de conf d'origine sous Jessie)

  • # Percona wizard,

    Posté par (page perso) . Évalué à 1.

    Plutôt que de te conseiller d'augmenter telle valeur et d'en diminuer d'autre, je te propose d'utiliser mysqltuner ou le wizard de percona.com pour adapter ta configuration mysql à ton serveur.

    Sinon, pour quelles raisons utilise-tu myISAM ? Ce moteur est obsolète.

    Cordialement

    • [^] # Re: Percona wizard,

      Posté par . Évalué à 2.

      Bonjour, comme précisé dans le message d'origine

      • les recommandations de mysqltuner n'ont rien changé

      Mais je vais tester le wizard de percona

    • [^] # Re: Percona wizard,

      Posté par . Évalué à 4.

      Ah et j'utilise MyIsam parce que cette base a plus de 10 ans, créée par un logiciel écrit en COBOL.

      Un jour je me pencherai sur le moyen de la convertir mais comme on dit "If it ain't broke, don't fix it" (ce que j'aurais dû ironiquement m'appliquer en n'essayant pas d'optimiser un truc qui marchait, je sais …)

  • # Configuration système

    Posté par (page perso) . Évalué à 1.

    Comme tu as rétabli la configuration d'origine, le changement de serveur doit causer le problème.
    Déjà regarde si par hasard ton CPU n'est pas trop chaud et ne perd pas des cycles pour limiter la surchauffe…
    Peut-être que tu es sur une configuration NUMA ? NUMA peut causer des comportements erratiques avec MySQL: NUMA and MySQL.
    Peut-être as-tu les transparent huge pages activées ? Ça peut poser des problèmes aussi.
    Tu peux aussi utiliser "perf top" pour savoir où vont tes cycles CPUs.
    As-tu changé de version de MySQL en changeant de serveur ? Le temps CPU est-il consommé principalement par le processus MySQL ? Est-il principalement consommé en mode user, system ou wait ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.