Alors pour répondre à Framasky : non je n'ai pas utilisé mysqltuner.
Je me méfie toujours des scripts qui font tout et qui appliquent une politique générale selon des règles qui se voudraient universelles. Les règles de tuning MySQL sont compliquées à prédire puisqu'elles dépendent de l'applicatif et de la machine (il n'y a qu'à faire un tour sur le site de Percona pour se rendre compte que même la documentation officielle MySQL raconte parfois n'importe quoi).
Du coup, pour le réglage de MySQL, c'est simple : comme le projet de remplacement des machines étaient planifiées, j'ai travaillé sur les anciennes machine en modifiant quelques paramètres. Si la performance n'était pas dégradée, je validais le paramètre, sinon je revenais en arrière. Donc au moment de la migration, j'étais iso-configuration. Je n'ai pas été trop loin car nous ne cherchons pas la microseconde : nos machines sont très correctes et loin d'être saturées.
Avant l'entrée en fonction de cette machine, j'ai qualifié la modification de trois paramètres :
* 'innodb_io_capacity' qui était à 1200 et qui a été descendu à 200
* 'table_open_cache' et 'table_definition_cache' qui ont été augmentés à 1000 chacun (au lieu de 64 et 400 ; soit les valeurs par défaut). L'amélioration est très légère mais réelle caches chauds.
Pour cette migration j'ai, en plus, modifié 'innodb_buffer_pool_size' pour passer de 10G à 64G (testé et approuvé auparavant sur d'autres machines ; en prod à l'heure actuelle). J'ai quand même effectué le test à 10G (au cas ou) et ce n'est pas ça.
Comme les performances ne sont pas bonnes, j'ai :
modifié 'innodb_log_file_size' pour passer de 500 Mo à 2047 Mo : aucune amélioration
modifié 'innodb_io_capacity' pour remonter à 1200 le temps d'un test : aucune amélioration
Pour répondre à Francesco :
MySQL 5.5.40 des deux côtés et même configuration (sauf 'innodb_buffer_pool_size' mais j'ai testé avec la même valeur et ça ne vient pas de ça)
kernel 3.17.7-r1 hardened des deux côtés et même configuration
oui l'environnement est le même des deux côtés (gcc 4.8.3 / profile hardened / use flag identiques sur tous nos serveurs SQL)
niveau système de fichier : EXT4 des deux côtés, 'noatime' des deux côtés.
La seule différence est au niveau du raid.
La machine ne swap pas ; n'a pas d'io wait en particulier ; ne charge pas niveau cpu ; n'a aucune erreur dans les logs).
J'ai déjà eu des performances désastreuses sur MySQL avec des serveurs dont le raid était matériel mais c'était lié au cache de la carte raid qui n'était pas actif. Par contre, dans le cas de mdadm, je sèche complètement.
Je me demandais si l'option de montage 'data' ('ordered' à l'heure actuelle) n'était pas une piste mais je ne trouve pas grand chose qui explique les différentes options...
# Réponses aux questions
Posté par kortex . En réponse au message MySQL - Gros problème de performance. Évalué à 1.
Bonsoir,
Désolé effectivement j'ai loupé quelques détails.
Alors pour répondre à Framasky : non je n'ai pas utilisé mysqltuner.
Je me méfie toujours des scripts qui font tout et qui appliquent une politique générale selon des règles qui se voudraient universelles. Les règles de tuning MySQL sont compliquées à prédire puisqu'elles dépendent de l'applicatif et de la machine (il n'y a qu'à faire un tour sur le site de Percona pour se rendre compte que même la documentation officielle MySQL raconte parfois n'importe quoi).
Du coup, pour le réglage de MySQL, c'est simple : comme le projet de remplacement des machines étaient planifiées, j'ai travaillé sur les anciennes machine en modifiant quelques paramètres. Si la performance n'était pas dégradée, je validais le paramètre, sinon je revenais en arrière. Donc au moment de la migration, j'étais iso-configuration. Je n'ai pas été trop loin car nous ne cherchons pas la microseconde : nos machines sont très correctes et loin d'être saturées.
Avant l'entrée en fonction de cette machine, j'ai qualifié la modification de trois paramètres :
* 'innodb_io_capacity' qui était à 1200 et qui a été descendu à 200
* 'table_open_cache' et 'table_definition_cache' qui ont été augmentés à 1000 chacun (au lieu de 64 et 400 ; soit les valeurs par défaut). L'amélioration est très légère mais réelle caches chauds.
Pour cette migration j'ai, en plus, modifié 'innodb_buffer_pool_size' pour passer de 10G à 64G (testé et approuvé auparavant sur d'autres machines ; en prod à l'heure actuelle). J'ai quand même effectué le test à 10G (au cas ou) et ce n'est pas ça.
Comme les performances ne sont pas bonnes, j'ai :
Pour répondre à Francesco :
La seule différence est au niveau du raid.
La machine ne swap pas ; n'a pas d'io wait en particulier ; ne charge pas niveau cpu ; n'a aucune erreur dans les logs).
J'ai déjà eu des performances désastreuses sur MySQL avec des serveurs dont le raid était matériel mais c'était lié au cache de la carte raid qui n'était pas actif. Par contre, dans le cas de mdadm, je sèche complètement.
Je me demandais si l'option de montage 'data' ('ordered' à l'heure actuelle) n'était pas une piste mais je ne trouve pas grand chose qui explique les différentes options...