Dans un de ses récents billets, Matt Yonkovit a déclenché une série de réflexions intéressantes à propos de l’impact des performances des disques durs sur l’ensemble du SGBD.

Selon lui, les problèmes de performance au sein d’un SGBD sont la plupart du temps relatifs aux disques durs et notamment au nombre d’I/O (Entrées/Sorties) qu’ils sont capables de traiter par seconde (IOPS).

Comparés aux processeurs actuels capables de prendre plusieurs milliards de décisions par seconde (Ghz) et aux mémoires vives dont les temps d’accès se mesurent en nanosecondes, le temps d’accès d’un disque dur se compte encore en millisecondes… Difficile de lutter contre des éléments purement électroniques quand on est constitué d’éléments mécaniques en mouvement (têtes de lecture, plateaux…).

Afin d’avoir recours le moins possible aux disques, l’utilisation des index est une première étape qu’on complètera par différents mécanismes de caching afin de limiter encore davantage les accès à ce support et éviter ainsi que le disque ne constitue un goulet d’étranglement (« I/O bound »).

Outre ces mécanismes, la technologie SSD pourrait bien à l’avenir changer la donne.

Les SSD, littéralement Solid-State Drives (ou Disk par abus de langage), ne sont pas des disques mais des unités de stockage constituées de mémoire flash (persistante).

Au vu des benchmarks les concernant, il y’a fort à parier que les SSD seront de plus en plus d’actualité dans les mois qui viennent.
Ces benchmarks sont unanimes sur un point : les SSD obtiennent d’excellentes performances lors des random read, laissant loin derrière les disques « classiques ». Grosse ombre au tableau néanmoins : les tests effectués sur des random write ne sont pas aussi concluants. Pourquoi ?

Sur un disque classique un « random read » entraîne (du plus couteux au moins couteux) :
- le déplacement de la tête de lecture/écriture sur la bonne piste (« seek time »)
- une fois la tête sur la bonne piste, il faut encore repérer sur celle-ci le bloc secteur demandé (« rotational latency »)
- la lecture et la transmission de la donnée vers le système.

Avec un SSD, le même « random read » est beaucoup plus rapide : pas de tête de lecture à déplacer ni d’attente liée à la rotation d’un plateau. Conclusion, comptez environ 5 ms de temps d’accès à un secteur particulier pour un disque performant et environ 0.15 ms pour un SSD.

En revanche, lors d’une écriture, le SSD est par conception beaucoup plus lent qu’en lecture : la « préparation » obligatoire de l’importante zone dédiée à l’écriture (« erase block ») et un ensemble d’écritures spécifique à cette technologie pénalisent les performances.

Face à ce problème connu, des parades logicielles voient le jour et la plupart des constructeurs de SSD proposeront sûrement leur propre solution dans les mois à venir. Actuellement la technologie MFT (Managed Flash Technology) offre déjà de grandes améliorations (cf lien « benchmarks » ci-dessus, 3ème graphique). Les performances obtenues sont sensiblement égales lors des random read par rapport aux SSD classiques mais les résultats sont 30x supérieurs en random write par rapport aux SSD et 15x supérieurs aux disque durs.

Enfin, un autre signe que le SSD est très certainement une technologie d’avenir : un des plus récents moteurs pour MySQL, PBXT, est conçu pour fonctionner avec les SSD (pdf).

Pour résumer, concernant les SSD :

Avantages :
- Très rapide en random read
- Peu sensible à la fragmentation des fichiers : performances constantes.
- Fiabilité supérieure au HD (pas d’éléments mécaniques en mouvement)

Inconvénients des SSD :
- Prix
- Capacités en deça des disques actuels
- Durée de vie plus courte qu’un disque (nombres de cycles d’écriture limités)

Améliorations attendues (et en cours) :
- Chute des prix
- Augmentation des performances en écriture
- Augmentation de la capacité
- Meilleure répartition des écritures sur le support (augmentation du nombre de cycles écritures / durée de vie)

Si cette rapide présentation des SSD a aiguisé votre curiosité, voici quelques pistes pour aller plus loin :
- Le blog de Kevin Burton.
- La rubrique SSD sur Wikipédia (notamment les références en bas de page).

Il est conseillé en général de dédier un disque pour ces fichiers car beaucoup d’écriture entraîne une baisse de vos performances. Dans le cas qui nous intéresse, l’activité du CPU m’a très étonné. En effet jusqu’à 60% du temps CPU étaient utilisé par ‘USER’ juste en activant la réplication.

Suite à cela j’ai décidé avec mon ami Laurent de faire un peu de profiling… sommes nous un peu DBCSI? (comprenez database crime scene investigators ) Pour cela un outil intéressant est oprofile.

Pour tester ça, nous avons un DELL 2850 sous RHEL4 1 disque (hélas) et 2Go de RAM. Le programme de test à été exécuté pendant 30 minutes, et voila les résultats surprenant.

• Avec binlog

Profiling through timer interrupt
samples % image name symbol name
1680924 47.9708 /lib64/tls/libc-2.3.4.so __ctype_toupper_loc
1651101 47.1197 /usr/libexec/mysqld dict_create_foreign_constraints_low
54986 1.5692 /usr/libexec/mysqld yylex(void*, void*)
9083 0.2592 /usr/libexec/mysqld __do_global_ctors_aux
8541 0.2437 /usr/libexec/mysqld buf_pool_init
8284 0.2364 /lib64/tls/libc-2.3.4.so memcpy
5918 0.1689 /usr/libexec/mysqld my_snprintf_ucs2
4934 0.1408 /usr/libexec/mysqld log_buffer_flush_to_disk
4640 0.1324 /usr/libexec/mysqld my_strntod_ucs2
4268 0.1218 /usr/libexec/mysqld MD5Transform
3650 0.1042 /usr/libexec/mysqld my_parse_charset_xml

• Sans binlog

Profiling through timer interrupt
samples % image name symbol name
34847 9.7094 /usr/libexec/mysqld __do_global_ctors_aux
30416 8.4748 /lib64/tls/libc-2.3.4.so memcpy
30041 8.3703 /usr/libexec/mysqld buf_pool_init
20615 5.7439 /usr/libexec/mysqld my_snprintf_ucs2
17065 4.7548 /usr/libexec/mysqld my_strntod_ucs2
16656 4.6408 /usr/libexec/mysqld log_buffer_flush_to_disk
14908 4.1538 /usr/libexec/mysqld dict_create_foreign_constraints_low
9154 2.5506 /lib64/tls/libpthread-2.3.4.so pthread_mutex_trylock
8354 2.3277 /lib64/tls/libc-2.3.4.so __ctype_toupper_loc
8216 2.2892 /lib64/tls/libpthread-2.3.4.so pthread_mutex_unlock
5347 1.4898 /usr/lib/debug/lib/modules/2.6.9-22.ELsmp/vmlinux copy_user_generic
3380 0.9418 /usr/libexec/mysqld buf_flush_try_page

On remarque que lorsque les logs binaires sont activés, beaucoup de temps CPU est utilisé par cette fonction « dict_create_foreign_constraints_low ». Ce qui très étrange, car elle est supposé être utilisé lorsque d’une modification de DDL (création de tables,…) pour effectuer des vérifications sur les clés étrangères. Et sur cette application, même si nous sommes en InnoDB, il n’y en a aucune.

Des que nous aurons un peu de temps devant nous, nous referons le test sous MySQL 5.0.