Les disques SSD sont très performants, c'est communément admis, mais qu'en est-il en réalité. Les systèmes Linux présentent plusieurs schedulers d'entrées/sorties, lequel est le plus adapté aux disques SSD ?
Pour le savoir j'ai fait un certain nombre de mesures sur deux machines et avec plusieurs noyaux différents qui ont tous été compilés "à la maison".
Le scheduler IO peut facilement être modifié dynamiquement disque par disque en intervenant dans le répertoire "/sys/block", dans ce répertoire on trouve un répertoire par disque physique contenant tout ce qu'il faut, entre autres un répertoire "queue" :
ls -al /sys/block/sda/queue
total 0
drwxr-xr-x 3 root root 0 2010-01-27 15:00 .
drwxr-xr-x 8 root root 0 2010-01-27 14:59 ..
-r--r--r-- 1 root root 4096 2010-01-27 15:00 hw_sector_size
drwxr-xr-x 2 root root 0 2010-01-27 15:10 iosched
-rw-r--r-- 1 root root 4096 2010-01-27 15:10 iostats
-r--r--r-- 1 root root 4096 2010-01-27 15:10 logical_block_size
-r--r--r-- 1 root root 4096 2010-01-27 15:10 max_hw_sectors_kb
-rw-r--r-- 1 root root 4096 2010-01-27 15:10 max_sectors_kb
-r--r--r-- 1 root root 4096 2010-01-27 15:10 minimum_io_size
-rw-r--r-- 1 root root 4096 2010-01-27 15:10 nomerges
-rw-r--r-- 1 root root 4096 2010-01-27 15:10 nr_requests
-r--r--r-- 1 root root 4096 2010-01-27 15:10 optimal_io_size
-r--r--r-- 1 root root 4096 2010-01-27 15:10 physical_block_size
-rw-r--r-- 1 root root 4096 2010-01-27 15:10 read_ahead_kb
-rw-r--r-- 1 root root 4096 2010-01-27 15:00 rotational
-rw-r--r-- 1 root root 4096 2010-01-27 15:10 rq_affinity
-rw-r--r-- 1 root root 4096 2010-01-27 15:10 scheduler
Le fichier "scheduler" contient la liste des schedulers (elevator) disponibles dans votre noyau :
cat scheduler
[noop] anticipatory cfq deadline
Le scheduler actif est entouré de "[ ]" (brackets dans le texte).
Note : "anticipatory" a disparu dans le noyau 2.6.33.
Je vais tenter d'autres test plus représentatifs le la vie réelle (???) pour mieux mesurer l'influence (éventuelle ? ) du scheduler d'IO.Les tests réalisés sur plusieurs noyaux sont extrêmement longs et obligent à des "reboot" fréquents.
Commentaires sur les résultats.
- La dépendance des résultats au noyau est très forte (rappel : les noyaux sont compilés avec les mêmes options)
- Dans les tests "vraie vie" la différence SSD/SATA est soit invisible soit pas dans le sens prévu (tests GZIP)
- La dépendance par apport au scheduler d'IO est extrêmement faible et ne dépasse pas quelques pourcents.
- En lecture pure (test hdparm) les SSD sont nettement plus performants (jusqu'au noyau 2.6.32 ?)
Quelques tests réalisés sur le noyau 2.6.32 on donné des résultats catastrophiques pour le SSD, 20% moins bien que le disque classique aux tests hdparm.
J'ai récupéré et compilé un 2.6.33 (rc5) pour compléter les tableaux. Au niveau du test "hdparm" le résultat est très dégradé pour le SSD, par contre au niveau du test de compilation de 2.6.33 a fait des miracles.
Les mesures obtenues avec "hdparm" étant un peu "bizarres" avec les disques SSD à partir du noyau 2.6.32 je pense qu'une modification importante des schedulers IO est en cours, c'est confirmé par la disparition du scheduler "anticipatory" dans le 2.6.33. Ces modifications rendent les résultats de "hdparm" tellement bizarres (anormaux et irréguliers pour les SSD) que ces résultats sont à prendre avec des pincettes.
Dernières nouvelles les tests "hdparm" sont en cours de réfection avec un paramètre supplémentaire permettant un accès plus "direct" au hardware ( option --direct). Une nouvelle page est en préparation.