Tuning et Optimisation des performances de

MySQL
Mezgani Ali
August 31, 2009

Cet article va projeter quelques astuces afin de mieux comprendre l’impor-

tance de l’optimisation de la base de donnée MySQL, avant de s’attaquer au
codage (ou autre chose).
Définir les objectifs est la première étape de la conception d’un projet, Cette
étape cruciale est trop souvent ignorée ou bâclée se qui mène à des projets in-
complets ou bien une fois le projet complété à des applications inutiles des vraies
usines à gaz.

Objectifs :
* Tirer les performances maximales du matériel disponible.
* Eviter les temps d’arrêt des applications critiques.
* Eviter le ralentissement des applications en période de pointe.

Je devrais installer une machine pour une application faisant un usage intensif
du SGBD MySQL avec n concurrences, sur Linux. Cependant l’optimisation de
MySQL passera par trois composants :
* Optimisation du serveur MySQL
* Optimisation de la base de données
* Optimisation des requêtes

1 Optimisation du serveur MySQL :

La machine en question est une HP BL680c avec Six noyaux (core) Xeon,
dont une cadence de 2.40GHz chacun, un cache memory de 12288 KB et 16GB
de RAM, attaché via fibre channel (FCP-2) à un SAN storage qui n’est que le
MSA 2010fc.
C’est une machine puissante vu sa configuration, donc pour profiter de ces per-
formances au maximum, et pour avoir une installation de MySQL optimale, il
ne faut un peu de tuning de cette dernière, tout en choisissant le RAID corre-
spondant, le meilleur FS, passant par l’OS et ainsi jusqu’à la couche applicative,
chose qui va impliquer largement le rendement et le temps de réponse de la ma-
chine en question. Pour question esthétique nommons notre machine nibiru.

1
 RAID (Redundant Array of Inexpensive Disks) :
Une des premières questions à se poser, quel niveau de RAID nous allons utilisé
pour notre serveur de base de données. Probablement vers le RAID 10 si nous
avons plusieurs écritures sur la base, le RAID 10 est une meilleurs solution aussi
la plus chère pour les base de données nécessitantes une grande performance
I/O vu sa grande vitesse de lecture/écriture, par rapport aux autres RAID.
Donc pour implémenter le RAID 10 sur un spare de disque de 7TB, nous ne
profitons que du 3.5TB d’espace, chose que nous pouvons pas implémenter pour
le moment. Le cas ou nous avons plusieurs lectures par rapport aux nombre
écritures, le RAID 5 reste un bon choix, malgré qu’il est rapide en lecture et
lent en écriture, mais comme même rapide en écriture par rapport à un seul
disque.

HDD (Hard disk drive) et espace de stockage :

Notre espace de stockage est un MSA 2012fc qui contient 10 Seagate disque SAS
(Serial Attached SCSI system) de 750GB de 10k rpm, avec un transfert de data
de 3 jusqu’à 6 Gbit/s. La valeur moyenne de lecture avec activation du cache
disque depuis nibiru est de 5656 MB/s, cependant la valeur moyenne de lecture
avec activation du tampon disque est de 199 MB/s.
La vitesse moyenne d’écriture est de 500 MB/s qui est une vitesse optimale par
rapport aux autres bus de transfert de donnée disque/ordinateur tel le SATA,
PATA (IDE).
Dans le cadre de ce projet, nous aurons une partition libre de 3TB et qui en
sera complètement dédiée.

IO (Input/Output) :
Les I/O subsystem ou bien les ordonnanceurs des E/S, sont un ensemble de
processus responsable du déplacement des blocs de donnée entre le disque et
la mémoire. Ils sont complètement paramétrables, généralement les I/O subsys-
tem ne se comportent pas comme des simple FIFO (first in first out), mais ils
reposent sur certains algorithmes afin de gérer les blocs de données, on peut en
citer : cfq, noop,deadline, anticipatory.
Le choix d’un bon scheduler peut remarquablement influencer les performances
de notre machine nibiru, depuis la version 2.6.18 du kernel l’algorithme d’ordon-
nancement des E/S CFQ est activé par défault, et qui permet des importantes
performances, surtout pour les grosses applications qui nécessitent un grand
nombre d’opérations I/O. Le principe du cfq (Completely Fair Queuing) comme
son nom l’indique est maintenir une queue afin de distribuer la bande passante
E/S sur l’ensemble de requête E/S, selon certaines règles.
Pour plus d’information sur le temps de réponse des ces algorithmes consul-
ter le tableau d’après :

Timing MB/s — scheduler algorithms noop anticipatory deadline cfq

cached reads 5669 5637 5638 5683
buffered disk reads 192 192 193 222
disk writes 528 516 451 507
Ces tests sont basés sur le kernel 2.6.18-92.1.22.el5PAE, pour des résultats

2
plus complètes nous devons developper un peu plus cet étude, en prenant con-
sidération de plusieurs kernels et plusieurs systèmes de fichiers. Ces tests peuvent
être automatiser grâce au superbe tool sysbench developpé par Alexey Kopytov
(ingénieur logiciel @ MySQL AB).

OS (Operating system) :
Le serveur MySQL est préconisé pour un fonctionnement optimal sur SOLARIS,
néanmoins, il est possible de l’optimiser sur notre OS pour se rapprocher de son
rendement idéal.
le système d’exploitation existant actuellement sur nibiru est la CentOS re-
lease 5.2 (Final), sur une architecture i686 avec le kernel 2.6.18-92.1.22.el5PAE,
donc si vous faites attention vous pouvez remarquer que la présence du module
PAE (Physical address extension), a priori c’est une CentOS pour un processeur
32bit, pourtant notre machine est une intel 64bit, pourquoi ne pas installer une
CentOS x86-64 ? La réponse est simple le fait de passer de 32 bits à 64 bits
augmente la consommation de mémoire. Donc si un programme consomme 100
MB en 32 bits il consommera automatiquement plus en 64 bits. Pour le moment
l’OS correspond parfaitement à notre besoin pour 16GB de RAM.

FS (File system) :
En travaillant sur l’optimisation d’une base de donnée, penser au système de
fichiers correpondant est une étape obligatoire, tout au long de se projet d’op-
timisation.
A vrai dire et comme vous le savez un système de fichiers est une structure
de donnée qui sert à stocker les data sous format lisible ordonnée, tel que les
fichiers. chaque fichier est décrit par des métadata tel que les droit d’accès, le
propriétaire, ...
Cette procédure de stockage changent de file system à un autre, puisque il existe
plusieurs sur le terrain propriétaire et free tel que GPFS, QFS, XFS, EXT2/3/4,
JFS, REISERFS... J’ai travaillé sur un benchmarking de trois types de système
de fichiers (JFS, XFS, EXT3) sur une machine modeste et le résultat était bien
évidement pour le JFS, dû a son faible coup de consomation de CPU. JFS
repéresente le système de fichiers journalisé mis au point par IBM et qui est
disponible sous la licence GPL.
Pour plus de détails sur cette étude vous pouvez consultez mon blog Notez que
ce benchmarking ne projete pas réellement le comportement des système fichiers
(JFS, XFS, EXT3) face au MySQL. L’outil utilisé mène ses tests en créant un
grand nombre de fichiers (ce qui ne reflète pas vraiment ce que fait un SGBD).

MySQL :
Il est préconisé d’utiliser la version code source du serveur MySQL et de la
compiler en prenant en considération les différents paramètres du système à
savoir le jeu de caractère à utiliser, le micro-processeur ... Pour question de
rapidité et facilité durant le process d’installation et mise à jour, nous pouvons
biensure l’installer depuis les repository de la CentOS.

3
2 Optimisation de la base de données :
Avant de passer au tuning de notre SGBDR, plusieurs questions viennent à
l’esprit :
Quel moteur de stockage choisir InnoDB ou bien MyISAM ?
Quel sont les Input/Ouput methodes (random, sequential) ?
Quel est le nombre de connections par seconde ?
Quel est le nombre de threads crée par seconde ?
Quel est le nombre maximal de connections ?

Dans le cas de plusieurs connections concurrentes, notre choix du MySQL

engine sera Innodb qui est de plus en plus utilisé grace à sa méthode d’indexage,
InnoDB peut créer des index selon une table de hashages pour les requetes les
plus fréquentes et qui est plus rapide qu’aux index ordinaires basé sur les ar-
bres binaires. InnoDB supporte des transactions conforme aux propriétés ACID,
similaire à celui de PostgreSQL, ainsi que la gestion des clés étrangères.
InnoDB scale très bien ce qui reflète son utilisation dans la gestion des grands
volumes.

Parmis les mesures à prendre en considération afin d’adapter MySQL à notre

besoin, la modification du fichier my.cnf. Ci-dessous quelques examples :
* La spécification de la taille du tampon mémoire d’InnoDB (buffer memory),
pour ses dictionnaires d’informations, et ses structures internes de données.
* Innodb utilise un tampon de traitement (buffer pool) pour mettre en cache
les données et les index de tables. Sa valeur devrait être adjuster de 60 à 70 %
de la mémoire physique du serveur, cela semblerait suffisant car avec une valeur
trop grande la machine utilsera le swap.
* Nous allons limité la taille du fichier log du 25-100% du tampon mémoire.
Ainsi le temps de restauration ne sera pas long.
* Le tampon de logs doit être assez grand à peu près de 4 x la taille du file de
log.
* Eviter de trop augmenter le nombre des threads concurrents, a priori cela
dépend de notre algorithme d’ordonnancement des E/S. Donc une grand valeur
risque de crasher le service.

Dans le cas ou vous n’avez pas besoin de transaction ni de clé étrangère, My-
ISAM est votre choix pourvue ses importantes performances, notez que My-
ISAM est fournit par défault par MySQL.

3 Optimisation des requêtes :

MySQL permet d’analyser les requêtes et de connaı̂tre le temps et le plan
d’exécution. Ces informations permettent de comprendre ce qui rends les requêtes
lentes et d’en optimiser l’exécution. Un des pièges de SQL est que c’est un lan-
gage de haut niveau. Le rapport entre la commande qu’on tape et le travail que
doit faire la machine est beaucoup moins direct et beaucoup plus dur à saisir

4
qu’avec l’assembleur. Il est donc fréquent qu’une requête SQL qui n’aie pas l’air
bien méchante prenne des heures à s’exécuter. Heureusement, MySQL dispose
d’une excellent commande EXPLAIN qui explique ce qu’elle va faire et ce qui
va prendre du temps. Cependant prenez toujours votre temps afin de detecter
les requêtes lentes, et profiter de la commande EXPLAIN pour les analyser.

Arrivons vers la fin de ce draft, je pense que le meilleurs outil mis à dispo-
sitions de chaque ingénieur systèmes, est le livre ainsi, J’aimerais en profiter
pour recommender l’excellent livre High Performance MySQL sur l’éditeur or-
eilly, d’ailleurs qui devrait être dans la bibliothèque de la FONDEP. Et ceci est
un autre projet :)