Disques : performance
Disques : performance jppLa performance des disques.
Le premier article présente un moyen d'atteindre des débits disques plus importants : le "stripping".
Ces articles étalés sur une période supérieure à 10 ans montrent bien l'augmentation des performances de ces belles petites mécaniques (ou électroniques pour les SSD).
SSD, avec Linux c'est super
SSD, avec Linux c'est super jppSSD : depuis que l'on en parle j'avais envie de tester ce genre de bête.
J'ai craqué et cassé ma tire-lire pour pouvoir disposer d'un de ces trucs : "OCZ Vertex Turbo series" de 30Go avec un cache de 64Mo.
Par ailleurs mon système XEN étant le résultat de nombreuses migrations :
- Suse SLES 10
- Suse SLES 10 SP1
- Suse SLES 10 SP2
- Suse SLES 11
- OpenSuse 11.1
Son disque système devait commencer à être assez bizarre, j'ai décidé de "repartir à zéro" et d'utiliser mon nouveau disque comme disque système.
Tout ça c'était avant mon retour à Debian, pensez ma première machine Linux était une Debian avec un kernel 1.0.1.
J'ai sauvegardé sur un disque externe tout ce qui avait de la valeur (par exemple le répertoire "/etc" et d'autres bricoles).
Je démonte les disques de stockage de données par sécurité (2 x 1To en miroir car toutes mes Machines virtuelles sont dessus) , je les remettrai en service plus tard, on n'est jamais trop prudent ! Ne doutant de rien j'ai tenté d'installer une OpenSuse 11.2 en rc1 voir site http://www.opensuse.org . Après quelques ennuis de gravure (ISO mal récupérée ?), c'est bizarre comme cela énerve, j'ai enfin réussi à créer le CD miracle. Malheur, lors de l'installation de cette 11.2 il y a un problème de génération du fichier "initrd" et des erreurs diverses qui rendaient le système inutilisable. Je suis repassé sur une OpenSuse 11.1 (stable) dont j'avais le DVD et ... l'installation a foiré sur mon beau SSD tout neuf ... Après quelque réflexion, j'ai lu des bricoles sur les problèmes d'installation de systèmes sur des SSD, j'ai décidé de frapper un grand coup : j'ai réduit (sniff) fortement la vitesse du CPU (multiplicateur passé de 11x à 7x), en bref j'ai transformé ma belle machine en brouette ... et celà a fonctionné ! L'installation de la 11.1 s'est fort bien passée. J'ai admiré au passage la beauté de l'installeur OpenSuse dont les graphismes sont parfaits, toutes les options de formatage des partitions sont assez bien foutues (si l'on met l'écran à 1024x768 au moins ...) et tout se passe bien. J'ai abandonné la partition spécifique "BOOT" et tout mis dans une seule partition du SSD. Après le paramétrage de l'installation tout est automatique et s'est déroulé en à peu pres 30 minutes (malgré le 7x). Note : il vaut mieux "nommer" les partitions pour être dans la course, ma partition root se voit donc nommée "ROOT" (très original). Une seule partition sur l'ensemble du SSD (29,8 GO) nommée "ROOT" et montée par label. Après un arrêt pour remettre le multiplicateur à 11x le boot est super rapide, le chargement des logiciels presque instantané, OpenOffice apparait très rapidement sur l'écran, en bref c'est super agréable. Vive le SSD ! Comme je disposais toujours de mon DVD 11.2 et que j'avais un peu de temps j'ai décidé de refaire une installation de 11.2 avec le multiplicateur réduit à 7x, on efface tout et on recommence.
C'est parti :
- on redéfinit les partitions (idem à celle définies précedemment),
- on choisit les logiciels à installer (on utilise le bureau KDE car "gdm" ne fonctionne pas avec le kernel XEN.
- on crée les utilisateurs "de base" en faisant attention à ne pas leur configurer un login automatique, c'est ennuyeux par la suite
"Suivant" l'installation démarre ... après environ 15 minutes la machine reboote pour la phase de configuraton. Aucune erreur ... bizarre le système gère mal l'installation sur SSD lorsque l'on est à pleine vitesse ???? La phase de configuration automatique se lance et ne signale aucun problème. 5 minutes après je dispose d'un beau bureau Gnome avec couleurs personnalisées par Suse, avec un logo Suse stylisé en fond, très smart en vert olive et noir. Je vais voir un peu ce que cela donne après un reboot er remise en place du multiplicateur à 11X. Beagle est en train d'indexer je le laisse finir avant de rebooter. Une petite image de l'écran Gnome : 
C'est beau !
On configure le réseau, tiens la configuration est construite directement avec des ponts, il n'y aura peut-être pas d'ennuis avec les machines virtuelles.
Enfin on va rebooter et passer en vitesse normale, fini le ralenti.
Après reboot le système répond très bien, c'est super...
Essayons Xen maintenant, on reboote sur le noyau XEN et horreur l'écran graphique est tout bizarre, ce doit être une oeuvre abstraite. Mais, sans rigoler, l'accès est impossible en mode graphique et bloque le clavier si l'on a le malheur de cliquer.
La machine reste toutefois accessible par ssh ... essayons de lancer une MV par ssh, "xm new MV" puis "xm start MV", tiens cela a l'air de marcher ... la machine virtuelle est accessible de l'extérieur, une petite connexion en X permet un accès graphique normal à la MV, tout est donc normal à part cet écran graphique bloqué !
Je tente alors de passer par kdm au lieu de gdm, plus de GNOME mais du KDE.
En mode non-XEN tout est OK, le fonctionnement est parfait l'écran KDE est lui aussi très esthétique.
En mode XEN ... ce n'est pas mieux qu'avec GNOME l'écran graphique reste dans un état "bizarre" et tant que l'on a pas cliqué sur cet écran de malheur on peut commuter sur les terminaux caractère par Ctrl+Alt+Fn.
Vite un petit rapport de bug pour tenter d'aider à résoudre ce problème :
- Bug non encore répertorié (Release Candidate), tout est normal en 11.1, je l'ouvre
- Rapidement un début de solution : dire à XEN de n'utiliser que 4Go, ... et ça marche, la session X s'ouvre et on peut lancer une machine virtuelle en interactif.
- Une piste pour la solution de ce bug existe, une limite mémoire à 4Go cela me rappelle un système 32bits ! 'ai proposé de tester le patch dès qu'il sera disponible.
- 7 Novembre : le patch est disponible ... il concerne "vmalloc.c" qui semblait ne pas bien s'entendre avec Xen. Le patch passé on recompile le noyau sous un autre nom. Après ajout des lignes "qui vont bien" dans le fichier de configuration de grub (menu.lst) on teste et c'est OK !
Toute la mémoire est reconnue sous Xen, le serveur X se lance correctement, tout est pour le mieux dans le (presque) meilleur des mondes. J'espère que ce patch va être intégré dans la version définitive.
Evidemment ce n'est pas terrible de limiter à 4Go, je le vois mal sur un serveur de production (j'en connais à 64 Go) avec 2 douzaines de MV). Enfin je peux tester cette version 11.2 avec un XEN 3.4.1 dernier cri. Et cela marche assez bien.
Pour montrer que cela marche je ne résiste pas à montrer l'écran avec la MV sur laquelle je suis en train de travailler (KDE + Windows) : 
Cela prouve que tout marche !
En bref SSD c'est OK, à part lors de l'initialisation du système où quelque chose ne "suit" pas.
Tests de vitesse :
- Sur un RAID (miroir) SATA :
hdparm -t /dev/md1
/dev/md1:
Timing buffered disk reads: 232 MB in 3.00 seconds = 77.25 MB/sec - Sur le SSD :
hdparm -t /dev/sdc1
/dev/sdc1:
Timing buffered disk reads: 508 MB in 3.00 seconds = 169.26 MB/sec
Ces différences expliquent la réduction du temps de boot, le confort ressenti au chargement d'applications.
Temps de boot du système depuis le choix du noyau (GRUB) < 16 secondes pour l'invite de X, le système contient 4 disques de données (miroir et LVM) en plus du SSD et deux interfaces réseau ce qui rallonge le temps de boot.
En bref : SSD c'est presque OK ! Pour terminer, économisez votre SSD en lui évitant des ordres d'écriture dont il peut se passer, utiliser les options "nodiratime" et "relatime / noatime" dans le fichier /etc/fstab, voici la ligne correspondante dans mon propre fichier fstab :
UUID=e5a02c97-cba2-4198-9b7a-1b1d354143ba / ext3 relatime,nodiratime,errors=remount-ro 0 1
cela pourrait être aussi :
/dev/sda1 / ext3 relatime,nodiratime,errors=remount-ro 0 1
SSD : importance du TRIM
SSD : importance du TRIM jppLes disques SSD c'est bien, c'est super-rapide, mais cela souffre d'un certain handicap après de nombreuses mises à jour. Le contrôleur interne du SSD essaye de répartir l'utilisation des "blocs" afin de ne pas avoir un bloc ré-écrit en permanence qui ne manquerait pas de "s'user" avant les autres.
Le contrôleur interne du SSD a donc "besoin" de connaitre les blocs libérés afin de pouvoir les ré-attribuer. Or les systèmes de gestion de fichiers de Linux, s'ils libèrent les blocs d'un fichier détruit (et enregistrent ces blocs comme "libres) n'en informent pas le contrôleur interne du SSD, celui-ci se trouve donc, au bout d'un certain temps, "à court" de blocs qu'il sait pouvoir réattribuer.
Cet état de fait est très préjudiciable à la performance (surtout en écriture) lorsque le disque a un peu vécu.
Heureusement on trouve sur Sourceforge au sein du projet "hdparm" un logiciel (wiper) qui permet de transmettre au contrôleur interne du SSD les renseignements voulus (http://sourceforge.net/projects/hdparm/files/wiper-2.6.tar.gz) qui permet de réaliser l'opération.
Le seul problème est que mon disque (OCZ Vertex) était un peu "ancien" (version firmware 1.4) et qu'il faut être au moins en 1.5). Heureusement, OCZ a publié une image ISO qui permet de réaliser cette opération délicate, on peut la trouver à (http://www.ocztechnologyforum.com/staff/ryderocz/vertex/vertex_15.zip) qu'il faut dézipper, graver en ISO. Il faut ensuite booter sur le CD avec le SSD monté, le reste est expliqué sur l'écran, attention tous les SSD Vertex (même en version 1.4) ne sont pas "capables" de recevoir cette mise à niveau (???).
Nouveauté 1: il existe sur le site une version pour SSD "récalcitrants" (avec "fail" dans le nom, j'en avais un qui refusait la mise à jour "standard", avec cette version l'affreux SSD a parfaitement été mis à jour.
Nouveauté 2 : il existe maintenant une version 1.6 du soft des SSD que je vais essayer à l'occasion.
Attention, ces manipulations peuvent entraîner une perte de données !!! Un bon backup est nécessaire !!!
Dans mon cas où il s'agissait du disque "système", j'en ai réalisé une copie conforme sur un "vieux" disque SATA (dd est un très bon ami à moi) que j'ai ensuite testé (faut que ça boote !), avant de tenter les manip : "upgrade version firmware SSD" et "wiper".
Ces manipulations devraient disparaître peu à peu en fonction de l'évolution des noyaux, (il existe des outils intégrés pour Windows 7) et le noyau Linux devrait rapidement prendre en compte cette option.
En attendant il est nécessaire de recourir à des manipulations assez peu orthodoxes. Si on peut "wiperiser" un disque démonté il n'est pas possible de la faire sur le disque système, le mieux est probablement de disposer d'un CD (ou clé USB) avec un système minimal et le très fameux WIPER.
Toutefois il n'est pas besion d'exécuer cette manip tous les jours ! Sur un disque très chargé en écriture comme le mien (cela s'est calmé depuis) il a fallu plusieurs mois avant de ressentir le ralentissement en écriture, la lecture restait OK.
J'ai refait les tests "iozone" (il faut conserver les scripts !) lors desquels j'avais trouvé des performances "horribles" en écriture sur une machine et les résultats sont là : il faut trimer pour que le disque bosse à la vitesse max.
Note : cette machine avait servi à de nombreuses compilations (et installations) de noyaux et de différentes version de XEN, opérations qui réalisent énormément d'écritures.
Voici deux séries d'image dans le style AVANT/APRES bien connu des publicitaires .... mais ce n'est pas du rêve, c'est bien la réalité
| Avant | Après |
"Write"  |
 |
Random Write  |
 |
Record Write  |
 |
C'est assez spectaculaire, et c'est bien, physiquement, le même disque ... vive le TRIM.
Une séance de trim :
1) Test sans valider, "pour voir"
# ./wiper.sh /dev/sdb2
wiper.sh: Linux SATA SSD TRIM utility, version 2.6, by Mark Lord.
Hdparm version
Target=/dev/sdb2 Method=offline
Preparing for offline TRIM of free space on /dev/sdb2 (ext3 non-mounted).
This will be a DRY-RUN only. Use --commit to do it for real.
Syncing disks..
Simulating TRIM operations..
(dry-run) trimming 37690664 sectors from 8058 ranges
Done.
2) Un passage "en vrai" :
./wiper.sh /dev/sdb2 --commit
wiper.sh: Linux SATA SSD TRIM utility, version 2.6, by Mark Lord.
Hdparm version
Target=/dev/sdb2 Method=offline
Preparing for offline TRIM of free space on /dev/sdb2 (ext3 non-mounted).
This operation could silently destroy your data. Are you sure (y/N)? y
Syncing disks..
Beginning TRIM operations..
/dev/sdb:
trimming 37690664 sectors from 8058 ranges
succeeded
Done.
Et en plus c'est très rapide, moins d'une minute. Le seul problème est que cela ne fonctionne pas sur un disque monté et un disque système non monté c'est légèrement gênant !
Mais si l'on a un autre disque bootable il n'y a aucun problème, on peut aussi démarrer sur un Live CD sur lequel on a installé le logiciel adéquat. J'ai deux disques bootables sur deux versions différentes du système dont une "stable", donc pas de problème de ce coté.
Le support du "TRIM" est partiel depuis le noyau 2.6.32 et limité aux filesystems "btrfs" (2.6.32) et "ext4" (2.6.33) en utilisant l'option "discard" dans la déclaration du périphérique dans "fstab", exemple :
/dev/sda1 / ext4 defaults,noatime,discard 0 0
Il va falloir passer le disque système en ext4, est-ce déjà judicieux ?
SSD : 2016 le TRIM
SSD : 2016 le TRIM jppLe "TRIM" est toujours important mais les noyaux et les" file systems" récents offrent des possibilités d'automatisation des actions de TRIM.
Au niveau du fichier "fstab" :
L'apparition d'une nouvelle possibilité "discard" permet d'automatiser la gestion du TRIM en la laissant au système, il faut pour cela disposer de noyaux assez récents et je ne sais plus quelle version a apporté cette nouveauté.
Exemple de déclaration "fstab" :
LABEL=LOG1 /LOG/LOG1 ext4 auto,noatime,relatime,discard 2 0
Au niveau de LVM :
Il est là aussi possible de spécifier une option automatisant le TRIM au niveau de LVM, ceci se fait dans le fichier "lvm.conf".
Exemple de déclaration dans le fichier /etc/lvm/lvm.conf :
issue_discards = 1
Ce fichier est par ailleurs très bien commenté (au moins sur une Debian).
Après ces petites interventions, et un reboot, plus de soucis de trim sur vos beaux SSD qui garderont une performance optimale, probablement au prix d'une légère diminution de leur durée de vie.
SSD : trim
SSD : trim jppCe "Livre" regroupe quelques articles sur le "TRIM", le premier, très ancien, vous pensez il remonte à 2010.
Il y a eu pas mal de nouveautés, tant au niveau du système que du matériel que j'mis un "chapeau" au premier article et écrit un nouvel article en montrant les possibilités des noyaux Linux récents.
Une description récente des possibilités tant au niveau de la "fstab" que de LVM.
SSD : mesures
SSD : mesures jppLes 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.
SSD : mesures hdparm V0
SSD : mesures hdparm V0 jppLes tests ont été refaits avec de nouveaux noyaux.
La première série de tests a été réalisée avec l'utilitaire "hdparm" dont l'option "-t" permet de mesurer un débit IO en lecture.
Pour les machines que j'ai utilisées il s'agit des disques sda,sdb,sdc,sdd. L'une de ces machines est munie de disques en miroir, il a donc été nécessaire d'agir sur deux disques simultanément pour changer de scheduler.
Premier test.
Les résultats sont les suivants (valeurs en MO/seconde, le plus fort est le mieux !) :
| RAM 8GO | Quadcore kernel 2.6.30-2 | ||||||
| hdparm | hdparm | hdparm | hdparm | TOTAL | |||
| SSD RAID | Noop | 115,51 | 107,73 | 104,52 | 327,76 | 33,564% | X |
| CFQ | 100,90 | 107,83 | 114,66 | 323,39 | 33,117% | ||
| Deadline | 119,11 | 100,42 | 105,84 | 325,37 | 33,319% | ||
| 335,52 | 315,98 | 325,02 | 976,52 | ||||
| SATA RAID | Noop | 75,59 | 75,29 | 75,11 | 225,99 | 33,481% | X |
| CFQ | 75,25 | 73,39 | 75,66 | 224,30 | 33,231% | ||
| Deadline | 76,06 | 75,11 | 73,52 | 224,69 | 33,288% | ||
| 226,90 | 223,79 | 224,29 | 674,98 | SATA/SSD | 69,12% | ||
| RAM 8GO | Dualcore kernel 2.6.31 | ||||||
| hdparm | hdparm | hdparm | hdparm | TOTAL | |||
| SSD | Noop | 133,35 | 132,61 | 131,89 | 397,85 | 33,241% | |
| CFQ | 131,36 | 132,33 | 134,13 | 397,82 | 33,238% | ||
| Deadline | 133,63 | 133,96 | 133,61 | 401,20 | 33,521% | X | |
| 398,34 | 398,90 | 399,63 | 1196,87 | ||||
| SATA RAID | Noop | 68,91 | 69,31 | 69,29 | 207,51 | 32,097% | |
| CFQ | 73,13 | 73,26 | 73,15 | 219,54 | 33,958% | X | |
| Deadline | 73,12 | 73,03 | 73,31 | 219,46 | 33,945% | ||
| 215,16 | 215,60 | 215,75 | 646,51 | SATA/SSD | 54,02% | ||
| RAM 8GO | Quadcore kernel 2.6.32 | ||||||
| hdparm | hdparm | hdparm | hdparm | TOTAL | |||
| SSD RAID | Noop | 77,18 | 61,33 | 71,93 | 210,44 | 27,693% | |
| CFQ | 79,72 | 102,37 | 98,66 | 280,75 | 36,946% | X | |
| Deadline | 75,83 | 92,08 | 100,79 | 268,70 | 35,360% | ||
| 232,73 | 255,78 | 271,38 | 759,89 | ||||
| SATA RAID | Noop | 75,25 | 74,33 | 73,52 | 223,10 | 33,258% | |
| CFQ | 73,47 | 75,73 | 75,64 | 224,84 | 33,517% | X | |
| Deadline | 75,77 | 73,64 | 73,47 | 222,88 | 33,225% | ||
| 224,49 | 223,70 | 222,63 | 670,82 | SATA/SSD | 88,28% | ||
| RAM 8GO | Quadcore kernel 2.6.33-rc5 | ||||||
| hdparm | hdparm | hdparm | hdparm | TOTAL | |||
| SSD RAID | Noop | 71,98 | 75,83 | 92,32 | 240,13 | 36,264% | |
| CFQ | 60,95 | 60,86 | 59,73 | 181,54 | 27,416% | ||
| Deadline | 89,27 | 76,18 | 75,06 | 240,51 | 36,321% | X | |
| 222,20 | 212,87 | 227,11 | 662,18 | ||||
| SATA RAID | Noop | 73,52 | 74,34 | 75,82 | 223,68 | 33,373% | |
| CFQ | 76,77 | 73,98 | 73,80 | 224,55 | 33,502% | X | |
| Deadline | 73,43 | 75,21 | 73,38 | 222,02 | 33,125% | ||
| 223,72 | 223,53 | 223,00 | 670,25 | SATA/SSD | 101,22% | ||
Constatation 1 :
Les résultats sont très serrés, les différences sont peu marquantes et ne font en général que quelques pourcents.
Constatation 2 :
Les résultats sont différents sur la même machine avec des noyaux différents.
Constatation 3 :
Les résultats SSD sont meilleurs sur le Dualcore ... c'est normal, il ne s'agit pas du même SSD mais d'un modèle vendu comme plus performant (et cela a l'air vrai) ... mais malheureusement nettement plus cher.
Les résultats obtenus avec un noyau > 2.6.32 sont un peu bizarres, à partir du 2.6.33 un des schedulers a disparu, je n'ai pas trouvé trace du "anticipatory scheduler", il ne reste que NOOP, CFQ et DEADLINE, les résultats sont comme pour le 2.6.32 très bizarres sur la partie SSD et se tiennent bien sur la partie SATA. J'ai oté toutes référence au scheduler "anticipatory" pour avoir des tableaux comparables sur toutes les versions.
Le SSD présente des anomalies importantes de vitesse sur les noyaux récents :
- Noyau 2.6.32
- Mini de 61,33
- Maxi de 102,37 soit un écart de plus de 60% !
- Alors que la partie SATA présente un écart inférieur à 3%.
- Noyau 2.6.33
- Mini de 59,73
- Maxi de 92,32 soit un écart de près de 60%
- Alors que la partie SATA présente un écart inférieur à 5%.
Les tests "hdparm" semblent complètement dépassés pour les dernières versions du noyau. Les indications relatives de ce test ne sont valables que pour les noyaux < 2.6.32. D'autre part les améliorations apportées par les noyaux >= 2.6.32 sont bel et bien ressenties à l'utilisation, voir les tests de compilation.
Voir aussi la page sur les nouveaux tests "hdparm" éxécutés avec l'option " --direct" permettant d'utiliser plus directement le hardware.
SSD : mesures hdparm V1
SSD : mesures hdparm V1 jppLa première version des tests présentait des anomalies de performance et une grande irrégularité. J'ai "découvert" une option complémentaire de cet utilitaire ( --direct ) permettant d'atteindre plus directement le hardware en évitant le passage par les buffers système. Ce type d'option (utilisant le flag "O_DIRECT" du noyau) est d'ailleurs recommandé pour les bases de données afin d'éviter de multiples recopies en mémoire sources de perte de performance.
- Sans "O_DIRECT" les données effectuent le transit suivant : HARDWARE --> page cache --> programme utilisateur.
- Avec "O_DIRECT" le transit est plus direct : HARDWARE --> programme utilisateur
Cela se voit d'ailleurs dans les résultats qui représentent ainsi mieux les performances "brutes" du hardware (les valeurs indiquées sont en MO/seconde).
Dualcore (SSD rapide) :
| RAM 8GO | Dualcore kernel 2.6.31 | ||||||
| hdparm -t | 1 | 2 | 3 | TOTAL | |||
| SSD RAID | Noop | 201,87 | 207,80 | 203,05 | 204,24 | 103,873% | X |
| CFQ | 154,12 | 202,68 | 204,47 | 187,09 | 95,151% | ||
| Deadline | 189,17 | 203,52 | 202,94 | 198,54 | 100,976% | ||
| 181,72 | 204,67 | 203,49 | 196,62 | ||||
| SATA RAID | Noop | 73,50 | 69,23 | 73,48 | 72,07 | 100,721% | X |
| CFQ | 69,26 | 73,22 | 69,58 | 70,69 | 98,787% | ||
| Deadline | 73,20 | 69,32 | 73,20 | 71,91 | 100,492% | ||
| 71,99 | 70,59 | 72,09 | 71,55 | SSD/SATA | 274,79% | ||
| RAM 8GO | Dualcore kernel 2.6.33 | ||||||
| hdparm -t | 1 | 2 | 3 | TOTAL | |||
| SSD RAID | Noop | 201,06 | 202,40 | 201,43 | 201,63 | 101,058% | X |
| CFQ | 198,19 | 197,41 | 199,59 | 198,40 | 99,437% | ||
| Deadline | 198,50 | 198,60 | 198,50 | 198,53 | 99,505% | ||
| 199,25 | 199,47 | 199,84 | 199,52 | ||||
| SATA RAID | Noop | 68,99 | 69,07 | 69,12 | 69,06 | 99,722% | |
| CFQ | 69,06 | 69,54 | 69,31 | 69,30 | 100,074% | ||
| Deadline | 69,72 | 69,23 | 69,23 | 69,39 | 100,204% | X | |
| 69,26 | 69,28 | 69,22 | 69,25 | SSD/SATA | 288,11% |
Quadcore (SSD "lent") :
| RAM 8GO | Quadcore kernel 2.6.31 | ||||||
| hdparm -t | 1 | 2 | 3 | TOTAL | |||
| SSD RAID | Noop | 144,79 | 144,42 | 101,67 | 130,29 | 105,715% | X |
| CFQ | 125,20 | 144,35 | 101,65 | 123,73 | 100,392% | ||
| Deadline | 144,39 | 101,12 | 101,66 | 115,72 | 93,893% | ||
| 138,13 | 129,96 | 101,66 | 123,25 | ||||
| SATA RAID | Noop | 75,62 | 73,62 | 76,04 | 75,09 | 100,341% | |
| CFQ | 73,41 | 75,83 | 73,54 | 74,26 | 99,228% | ||
| Deadline | 75,83 | 73,58 | 76,07 | 75,16 | 100,431% | X | |
| 74,95 | 74,34 | 75,22 | 74,84 | SSD/SATA | 164,69% | ||
| RAM 8GO | Quadcore kernel 2.6.33 | ||||||
| hdparm -t | 1 | 2 | 3 | TOTAL | |||
| SSD RAID | Noop | 137,88 | 137,87 | 137,87 | 137,87 | 103,297% | X |
| CFQ | 137,85 | 137,84 | 137,86 | 137,85 | 103,280% | ||
| Deadline | 137,82 | 137,87 | 98,39 | 124,69 | 93,423% | ||
| 137,85 | 137,86 | 124,71 | 133,47 | ||||
| SATA RAID | Noop | 75,78 | 75,85 | 75,87 | 75,83 | 100,066% | X |
| CFQ | 75,71 | 75,69 | 75,81 | 75,74 | 99,938% | ||
| Deadline | 75,78 | 75,71 | 75,85 | 75,78 | 99,996% | ||
| 75,76 | 75,75 | 75,69 | 75,78 | SSD/SATA | 176,12% |
Les résultats sont un peu irréguliers pour le SSD ce qui "baisse" la moyenne à 123MO/seconde en 2.6.31 et 133MO/seconde pour le noyau 2.6.33.
Autre machine (ATOM N330) :
J'ai fait faire les tests sur un nouveau "petit" serveur (ATOM N330) avec lequel on obtient les résultats suivants :
| RAM 2GO | MINIITX kernel 2.6.33 | ||||||
| hdparm -t | 1 | 2 | 3 | TOTAL | |||
| SSD RAID | Noop | 148,34 | 152,50 | 149,89 | 150,24 | 100,647% | X |
| CFQ | 149,63 | 154,00 | 143,41 | 149,01 | 99,823% | ||
| Deadline | 144,02 | 148,59 | 153,12 | 148,58 | 99,530% | ||
| 147,33 | 151,70 | 148,81 | 149,28 | ||||
| SATA RAID | Noop | 73,59 | 73,52 | 73,33 | 73,48 | 100,041% | X |
| CFQ | 73,52 | 73,56 | 73,35 | 73,48 | 100,036% | ||
| Deadline | 73,30 | 73,45 | 73,43 | 73,39 | 99,923% | ||
| 73,47 | 73,51 | 73,37 | 73,45 | SSD/SATA | 203,24% |
Ce qui n'est pas mal du tout pour une petite machine.
Il a juste fallu ajouter un disque SATA de 160Go (8Mo cache) dans la belle boîte pour faire ces tests.
SSD : mesures gzip
SSD : mesures gzip jppDeuxième test.
Devant ces résultats un peu théoriques j'ai essayé de faire d'autres mesures peut-être plus représentatives. J'ai donc mesuré le temps de "dézipper" et de "rezipper" les sources du noyau "linux-2.6.31.6.tar.gz" soit à peu près 79Mo zippés et # 380Mo dézippés.
Les commandes exécutées sont :
sync
cd $REP
gzip -d linux-2.6.31.6.tar.gz
sync
gzip linux-2.6.31.6.tar
sync
Et la durée "ellapsed" de l'ensemble est mesurée par la commande "time" dont le résultat "real" est repris dans les tableaux.
Trois séries de tests ont été exécutées pour chacun des schedulers disponibles.
| RAM 8GO | Quadcore kernel 2.6.30.2 | |||||||
| Gzip | Gzip | Gzip | Gzip | TOTAL | ||||
| SSD RAID | Noop | 38,20 | 35,14 | 36,03 | 109,37 | 24,726% | X | 24,726% |
| CFQ | 38,06 | 37,20 | 36,50 | 111,76 | 25,267% | |||
| Anticip | 36,84 | 36,20 | 37,17 | 110,21 | 24,916% | |||
| Deadline | 38,89 | 36,07 | 36,02 | 110,98 | 25,091% | |||
| 151,99 | 144,61 | 145,72 | 442,32 | |||||
| SATA RAID | Noop | 25,88 | 26,08 | 26,14 | 78,10 | 25,006% | 24,853% | |
| CFQ | 26,21 | 26,11 | 26,25 | 78,57 | 25,157% | |||
| Anticip | 25,90 | 25,95 | 26,18 | 78,03 | 24,984% | |||
| Deadline | 25,48 | 26,03 | 26,11 | 77,62 | 24,853% | X | ||
| 103,47 | 104,17 | 104,68 | 312,32 | |||||
| RAM 3GO | Quadcore kernel 2.6.31.4-xen (XEN) | |||||||
| Gzip | Gzip | Gzip | Gzip | TOTAL | ||||
| SSD RAID | Noop | 69,62 | 67,71 | 69,00 | 206,33 | 25,056% | 24,801% | |
| CFQ | 69,13 | 68,31 | 66,79 | 204,23 | 24,801% | X | ||
| Anticip | 69,78 | 67,77 | 69,32 | 206,87 | 25,122% | |||
| Deadline | 68,94 | 68,85 | 68,25 | 206,04 | 25,021% | |||
| 277,47 | 272,64 | 273,36 | 823,47 | |||||
| SATA RAID | Noop | 58,96 | 58,30 | 58,65 | 175,91 | 24,999% | X | 24,999% |
| CFQ | 58,43 | 58,91 | 58,58 | 175,92 | 25,000% | |||
| Anticip | 58,67 | 58,53 | 58,71 | 175,91 | 24,999% | X | ||
| Deadline | 58,30 | 59,51 | 58,12 | 175,93 | 25,002% | |||
| 234,36 | 235,25 | 234,06 | 703,67 | |||||
| RAM 8GO | Quadcore kernel 2.6.31.4-xen (XEN) | |||||||
| Gzip | Gzip | Gzip | Gzip | TOTAL | ||||
| SSD RAID | Noop | 73,08 | 74,02 | 71,39 | 218,49 | 24,943% | 24,904% | |
| CFQ | 74,30 | 72,18 | 73,82 | 220,30 | 25,150% | |||
| Anticip | 72,62 | 72,90 | 73,50 | 219,02 | 25,003% | |||
| Deadline | 73,35 | 73,03 | 71,77 | 218,15 | 24,904% | X | ||
| 293,35 | 292,13 | 290,48 | 875,96 | |||||
| SATA RAID | Noop | 62,21 | 62,09 | 62,24 | 186,54 | 24,985% | X | 24,985% |
| CFQ | 62,08 | 61,62 | 63,18 | 186,88 | 25,030% | |||
| Anticip | 62,09 | 61,70 | 62,85 | 186,64 | 24,998% | |||
| Deadline | 63,08 | 61,90 | 61,57 | 186,55 | 24,986% | |||
| 249,46 | 247,31 | 249,84 | 746,61 | |||||
Les résultats montrent que les SSD ne gagnent pas toujours ! Curieusement tous les tests sur le disque SSD sont très nettement moins bons, presque deux fois moins rapides !
Une analyse plus fine montre que les temps de dézippage sont quasiment identiques (# 3 secondes) mais les temps de zippage sont très différents, 30 secondes pour le SSD et 15 secondes pour le disque SATA. Les quelques seconds "manquantes" sont le fait des ordres "sync" destinés à forcer les écritures.
Je n'ai encore trouvé aucune explication à ce phénomène, mais visiblement ce test pose un problème aux disques SSD.
On remarque dans ces tableaux que deux noyaux assez proches (2.6.30 et 2.6.31) ont des temps de réponse très différents :
2.6.30 : durée totale des tests (8Go RAM) : 442 + 312 = 754
2.6.31 : durée totale des tests (3Go RAM) : 823 + 703 = 1526 soit grossièrement le double des temps du 2.6.30 !
2.6.31 : durée totale des tests (8Go RAM) : contre toute attente la durée totale est de plus de 1620 secondes soit 6% de plus qu'avec 3Go.
Je constate sans expliquer .....
SSD : mesures compilation
SSD : mesures compilation jppDevant les différents points d'interrogation posés par les tests précédents j'ai décidé de faire d'autres tests encore plus près de "la vie réelle" en réalisant un petit exercice de compilation.
J'ai pris comme "cobaye" le logiciel IPERF dans sa version 2.0.4 et réalisé les opérations suivantes :
- Création d'un répertoire de compilation sur le SSD /var/tmp/iperf-2.0.4
- Création d'un répertoire de compilation sur le disque SATA /RAIDZZZ/tempo/iperf-2.0.4
Chacun de ces répertoires comporte bien entendu l'arbre des sources de IPERF et une compilation a été réalisée "à la main". Les opérations réalisées par le script (mesurées par la commande "time" ) seront :
sync
cd $REP
make clean
rm -f config.status
./configure
make -j 2
sync
Les temps "real" figurent dans le tableau suivant ( valeurs en secondes, le plus faible est le mieux) :
| RAM 8GO | Dualcore kernel 2.6.31 | |||||||
| Compil | Compil | Compil | Compil | TOTAL | ||||
| SSD RAID | Noop | 14,98 | 15,30 | 15,08 | 45,36 | 33,324% | 33,257% | |
| CFQ | 15,02 | 15,17 | 15,08 | 45,27 | 33,257% | X | ||
| Deadline | 15,17 | 15,19 | 15,13 | 45,49 | 33,419% | |||
| 45,17 | 45,66 | 45,29 | 136,12 | |||||
| SATA RAID | Noop | 15,86 | 15,91 | 15,85 | 47,62 | 33,649% | 33,154% | |
| CFQ | 15,83 | 15,82 | 15,27 | 46,92 | 33,154% | X | ||
| Deadline | 15,93 | 15,33 | 15,72 | 46,98 | 33,197% | |||
| 47,62 | 47,06 | 46,84 | 141,52 | SATA/SSD | 103,97% | |||
| RAM 3GO | Quadcore kernel 2.6.31-4-xen | |||||||
| Compil | Compil | Compil | Compil | TOTAL | ||||
| SSD RAID | Noop | 28,80 | 27,86 | 27,71 | 84,37 | 33,190% | 33,068% | |
| CFQ | 27,89 | 28,30 | 27,87 | 84,06 | 33,068% | X | ||
| Deadline | 28,18 | 28,32 | 29,27 | 85,77 | 33,741% | |||
| 84,87 | 84,48 | 84,85 | 254,20 | |||||
| SATA RAID | Noop | 28,83 | 28,17 | 27,93 | 84,93 | 33,377% | 33,149% | |
| CFQ | 28,27 | 28,52 | 28,39 | 85,18 | 33,475% | |||
| Deadline | 27,97 | 27,82 | 28,56 | 84,35 | 33,149% | X | ||
| 85,07 | 84,51 | 84,88 | 254,46 | SATA/SSD | 100,10% | |||
| RAM 3GO | Dualcore kernel 2.6.31-8-xen | |||||||
| Compil | Compil | Compil | Compil | TOTAL | ||||
| SSD RAID | Noop | 14,34 | 15,20 | 15,19 | 44,73 | 33,116% | X | 33,116% |
| CFQ | 15,11 | 15,13 | 15,23 | 45,47 | 33,664% | |||
| Deadline | 14,84 | 15,11 | 14,92 | 44,87 | 33,220% | |||
| 44,29 | 45,44 | 45,34 | 135,07 | |||||
| SATA RAID | Noop | 16,59 | 15,83 | 16,65 | 49,07 | 34,152% | 32,719% | |
| CFQ | 15,87 | 15,44 | 15,70 | 47,01 | 32,719% | X | ||
| Deadline | 15,85 | 15,90 | 15,85 | 47,60 | 33,129% | |||
| 48,31 | 47,17 | 48,20 | 143,68 | SATA/SSD | 106,37% | |||
| RAM 8GO | Quadcore kernel 2.6.30-2 | |||||||
| Compil | Compil | Compil | Compil | TOTAL | ||||
| SSD RAID | Noop | 14,48 | 14,39 | 14,28 | 43,15 | 33,538% | 33,103% | |
| CFQ | 14,24 | 14,07 | 14,28 | 42,59 | 33,103% | X | ||
| Deadline | 14,26 | 14,45 | 14,21 | 42,92 | 33,359% | |||
| 42,98 | 42,91 | 42,77 | 128,66 | |||||
| SATA RAID | Noop | 14,70 | 15,46 | 15,08 | 45,24 | 34,066% | 32,937% | |
| CFQ | 14,28 | 14,11 | 15,43 | 43,82 | 32,997% | |||
| Deadline | 14,35 | 14,79 | 14,60 | 43,74 | 32,937% | X | ||
| 43,33 | 44,36 | 45,11 | 132,80 | SATA/SSD | 103,22% | |||
| RAM 8GO | Quadcore kernel 2.6.32 | |||||||
| Compil | Compil | Compil | Compil | TOTAL | ||||
| SSD RAID | Noop | 11,09 | 10,38 | 10,24 | 31,71 | 34,031% | 32,958% | |
| CFQ | 10,19 | 10,33 | 10,19 | 30,71 | 32,958% | X | ||
| Deadline | 10,33 | 10,26 | 10,17 | 30,76 | 33,011% | |||
| 31,61 | 30,97 | 30,60 | 93,18 | |||||
| SATA RAID | Noop | 11,69 | 10,88 | 10,95 | 33,52 | 33,924% | 32,952% | |
| CFQ | 10,81 | 10,87 | 10,88 | 32,56 | 32,952% | X | ||
| Deadline | 10,97 | 10,90 | 10,86 | 32,73 | 33,124% | |||
| 33,47 | 32,65 | 32,69 | 98,81 | SATA/SSD | 106,04% | |||
| RAM 8GO | Quadcore kernel 2.6.33-rc5 | |||||||
| Compil | Compil | Compil | Compil | TOTAL | ||||
| SSD RAID | Noop | 10,17 | 10,16 | 10,21 | 30,54 | 33,217% | X | 33,217% |
| CFQ | 10,22 | 10,30 | 10,29 | 30,81 | 33,511% | |||
| Deadline | 10,17 | 10,17 | 10,25 | 30,59 | 33,272% | |||
| 30,56 | 30,63 | 30,75 | 91,94 | |||||
| SATA RAID | Noop | 10,22 | 10,28 | 10,30 | 30,80 | 33,315% | X | 33,315% |
| CFQ | 10,25 | 10,30 | 10,30 | 30,85 | 33,369% | |||
| Deadline | 10,22 | 10,28 | 10,30 | 30,80 | 33,315% | X | ||
| 30,69 | 30,86 | 30,90 | 92,45 | SATA/SSD | 100,55% | |||
| RAM 8GO | Dualcore kernel 2.6.33-rc6 | |||||||
| Compil | Compil | Compil | Compil | TOTAL | ||||
| SSD RAID | Noop | 12,62 | 12,19 | 12,06 | 36,87 | 33,601% | 32,963% | |
| CFQ | 12,00 | 12,19 | 11,98 | 36,17 | 32,963% | X | ||
| Deadline | 12,02 | 12,21 | 12,46 | 36,69 | 33,437% | |||
| 36,64 | 36,59 | 36,50 | 109,73 | |||||
| SATA RAID | Noop | 13,73 | 13,08 | 12,37 | 39,18 | 33,313% | 32,829% | |
| CFQ | 13,11 | 13,61 | 13,10 | 39,82 | 33,858% | |||
| Deadline | 12,74 | 12,81 | 13,06 | 38,61 | 32,829% | X | ||
| 39,58 | 39,50 | 38,53 | 117,61 | SATA/SSD | 107,18% | |||
Par ailleurs les différences entre les différents scheduler d'IO ne sont pas significatives sur ces tests car elles restent inférieures à 1%.Les temps sont meilleurs pour les deux types de disques dans les montées de version du noyau Linux.
Le temps total (9 exécutions) passe de #92 secondes pour le noyau 2.6.33 à #95 pour le 2.6.32 à #130 secondes pour le 2.6.30. Visiblement les développeurs du noyau ont bien travaillé et les progrès sont nettement visibles.
Cette série de tests montre un léger avantage au SSD par apport au disque "classique" une différence de 4 à 6% se manifeste en sa faveur.
SSD : mesures IOZONE
SSD : mesures IOZONE jppLa construction des tests progresse, les groupes de valeurs ont été choisis :
- Taille des fichiers testés : 4, 8, 16, 32, 64, 128, 256, 512 et 1024 MégaOctets
- Taille des enregistrements : 16, 32, 64, 128, 256 et 512 octets
Cela devrait donner des chiffres significatifs. Pour pouvoir effectuer ces tests pour plusieurs noyaux sur SSD et SATA classique un petit ensemble de scripts a été réalisé et pour présenter de jolis graphiques je me suis replongé dans "GNUPLOT" et après quelques scripts de traitement des données il me sera possible de présenter de jolis dessins.
Par contre l'acquisition des tests est très longue et se chiffre en heures pour un seul passage complet de tests.
Devant le peu de différences entre les différents schedulers les tests ne seront faits que pour le scheduler "noop", a priori le moins compliqué, qui devrait mieux représenter la performance "brute" des disques.
Les petits dessins et quelques commentaires sous peu ... dès que l'ensemble des tests aura "tourné" et que quelques commentaires seront disponibles ...
La commande utilisée ( ici fichier de 1024Mo, enregistrements de 32 caractères sur un disque SATA ) :
iozone -s 1048576 -r 32 -f /tempo/testio -I -o -M
- -s Taille du fichier en KO
- -r taille de l'enregistrement en cacartères
- -f fichier de travail (sur disque SATA ou SSD)
- -I Use VxFS VX_DIRECT, O_DIRECT,or O_DIRECTIO for all file operation
- -o Writes are synch (O_SYNC)
- -M Report uname -a output
8
Les tests sont réalisés sur deux machines possédant chacune des disques SSD et des SATA classiques :
- Amd dualcore 4400+ à 2.20 Ghz, 8 Go RAM, contrôleur SATA nvidia CK804, avec un SSD très rapide et deux disques SATA 1To en RAID1 (miroir).
- Amd quadcore 905e à 2,5Ghz, 8Go Ram, contrôleur ATI SB700/SB800, avec un SSD plus standard et deux disques SATA assez anciens de 160Go en RAID1 (miroir).
Cà y est enfin, j'ai toutes les données nécessaires, le processus est très long ... deux à quatre heures pour chaque noyau. Et en plus il ne faut pas toucher la machine pendant la prise de données pour ne pas fausser les résultats.
Les scripts préparés pour Gnuplot sont OK, ils génèrent bien les graphes escomptés, maintenant il faut essayer d'en extraire la quintessence pour la présenter. On peut déjà dire que certains résultats sont un peu curieux et n'ont pas d'explication immédiate, d'autres sont plus évidents et vont dans le sens prévu. Il semble toutefois que les disques SSD ne soient pas la panacée malgré un certain nombre d'avantages.
Il semble par ailleurs que "iozone" soit partiellement inadapté aux disques modernes munis de cache très importants. Les disques SATA ont 8Mo de cache sur la machine quadcore et 32Mo sur la machine dualcore. Les caches des disques SSD sont encore plus volumineux : 64 Mo.
Très bientôt les premiers résultats, la structure d'accueil est prête ...
SSD : IOZONE lecture
SSD : IOZONE lecture jppRésultats en lecture, tous les résultats sont donnés pour les deux versions de noyau choisies 2.6.31 et 2.6.33.
Dualcore
 |
 |
De grosses différences se manifestent, d'une part dans les "petits" fichiers où la taille du cache du disque semble prépondérante, le noyau 2.6.33 donne de superbes résultats sur le disque "classique" pour les petites tailles de fichiers, le SSD l'emporte dès que la taille des fichiers augmente. Le noyau 2.6.33 semble "brider" la performance du SSD.
Remarque : le SSD semble plus beaucoup plus sensible à la taille des enregistrements, il prend l'avantage dès que la taille des enregistrements dépasse 128 octets.
Quadcore :
 |
 |
La forme des courbes est beaucoup plus régulière que sur le dualcore, le SSD prends l'avantage dès les petites valeurs d'enregistrements et accentue son avance lorsque l'enregistrement s'allonge.
La vitesse maxi du SSD est moindre que pour le dualcore, ce qui semble normal au vu des types de disques. La courbe des disques SATA est plus régulière et plus "pentue" que pour le dualcore, est-ce une influence de la taille de cache beaucoup plus réduite.
Conclusion : avantage au SSD dès que la longueur des enregistrements dépasse 32, l'avantage s’accroît avec la taille des fichiers et celle des enregistrements.
SSD : IOZONE lecture random
SSD : IOZONE lecture random jppRésultats en lecture "random", tous les résultats sont donnés pour les deux versions de noyau choisies 2.6.31 et 2.6.33.
Dualcore
 |
 |
Les résultats sont bien ceux attendus, le SSD gagne haut la main. Le fait de ne pas avoir de délai rotationnel ni de temps de déplacement des têtes permet au SSD de dominer très largement dès que l'on sort un peu des caches (au delà de 32Mo). Le noyau 2.6.33 semble exploiter mieux les caches du disque "classique" pour les petits fichiers ( < taille du cache) où la vitesse atteint des sommets impressionnants.
Quadcore :
 |
 |
Les caches plus petits des disques classiques donnent un aspect beaucoup plus "lisse" aux graphes, le SSD gagne là aussi haut la main quel que soit le noyau. Les résultats sont équivalents pour les deux noyaux testés.
Conclusion : les disques SSD gagnent logiquement ce match, les délais (rotationnels et piste à piste) sont ici très défavorables qux disques "classiques".
SSD : IOZONE écriture
SSD : IOZONE écriture jppRésultats en écriture, tous les résultats sont donnés pour les deux versions de noyau choisies 2.6.31 et 2.6.33.
Dualcore
 |
|
Des résultats curieux, l'avantage reste au SSD mais le noyau 2.6.33 donne de très bonnes performances au disque "classique" en exploitant beaucoup mieux les caches (très visible sur les petites tailles de fichiers) alors qu'avec le 2.6.31 les résultats sont très faibles pour le disque "classique" sans aucune explication évidente.
Quadcore :
 |
|
Là c'est spécial, le SSD est très lent (!), alors que le SATA se comporte beaucoup mieux. Aucune explication évidente à part les contrôleurs disques et les drivers associés ou encore ce disque SSD pas bon en écriture ?
Conclusion : sur ce test une des deux machines donne un résultat contraire à la logique et franchement surprenant sans explication évidente. A ce sujet voir l'article sur le TRIM.
SSD : IOZONE écriture random
SSD : IOZONE écriture random jppRésultats en écriture "random", tous les résultats sont donnés pour les deux versions de noyau choisies 2.6.31 et 2.6.33.
Dualcore :
 |
 |
Les résultats sont "logiques" et montrent un net avantage au SSD qui tire avantage de sa structure "statique". Les caches permettent qu disque "classique" de faire illusion sur les fichiers de petite taille ( < taille du cache).
Quadcore :
 |
|
Même résultats "illogiques", le disque "classique" l'emporte sur le SSD dans la plupart des configurations sans aucune explication évidente.
Conclusion : sur le dualcore le SSD l'emporte de manière évidente, sur le quadcore il se passe quelque chose de très défavorable au SSD et les résultats du disque "classique" ne sont même pas bons. Une vérification s'impose au niveau du paramétrage de chaque système. Voir à ce sujet l'article sur le TRIM.
SSD : mesures, gnuplot
SSD : mesures, gnuplot jppAyant passé quelques heures à rechercher les "bons" paramètres pour gnuplot je ne résiste pas et vous livre le script qui permet de réaliser ces beaux dessins :
set terminal png size 600,800
# Paramètres
# X = COL 1 (taille fichier)
set xrange [4096:1200000]
set logscale x
set xtics ("4M" 4096,"8M" 8192,"16M" 16384,"32M" 32768,"64M" 65536,"128M" 131072,"256M" 262144,"512M" 524288,"1G" 1048576," " 1200000)
# Y = COL 2 (taille record)
set yrange [16:512];
set logscale y
set ytics (16,32,64,128,256,512)
# Z = valeur (affichée en "vertical")
set zrange [1000:45000]
set ztics 4500
set grid xtics ytics ztics
set title "Graphe pour write QUAD 2.6.33"
# rotation de l'image
# Paramètres 1 = haut bas, 2 = rotation "verticale", 3 = scale x, 4 = scale Y
set view 82,30,1,1
show view;
# paramètres des graphes
# pas toujours beau de cacher
# set hidden3d
set ticslevel 0
# Dessin de la courbe
set output './GR3D_write.png'
# Les valeurs sont 1 2 3
# Horiz Prof Vert
# --> seule la colonne 3 change
splot './GR3D_SATA.data' using 1:2:3 with linespoints title "Sata" ,\
'./GR3D_SSD.data' using 1:2:3 with linespoints title "SSD"
Les données issues de IOZONE se présentent sous la forme suivante :
4096 16 5186 16680 14973 16750 43991 19815 17172 35960 16189 271512 637599
41750 1252212
8192 16 1434 9323 28470 30851 49824 11009 12213 22726 23055 261390 647544
1321294 1332670
16384 16 2342 8505 34228 44150 49955 5517 23756 28867 29089 266250 645243 1329232 1349806
32768 16 1910 7892 46899 52612 49608 5493 31623 48795 40638 262227 637958 1308162 1318313
65536 16 1901 15269 57790 59384 50686 5318 38498 38474 45373 262871 636297 1325699 1338611
131072 16 2056 13492 50604 63858 50527 5627 46133 40310 48394 259907 629282
1303419 1313993
262144 16 2109 15342 56704 68718 48837 6939 49306 30937 49158 261380 648884 1312499 1319461
524288 16 2210 14232 67886 68860 49550 6104 49283 48960 49798 249599 626107 423431 1334324
Pour chaque longueur d'enregistrement. L'association du script et des données (pour toutes les longueurs d'enregistrement donne les jolis dessins suivants:
- En "horizontal" la taille de fichier (4M à 1024M)
- En "profondeur" la taille d'enregistrement (16 à 512)
- En "hauteur" la valeur de la donnée en KO/seconde
C'est y pas beau ?
Tester BTFRS
Tester BTFRS jppLe nouveau/futur système de fichiers pour Linux semble être BTRFS car celui-ci est censé apporter un certain nombre de nouveautés et de facilités que d'autres systèmes (Solaris 10?) possèdent et qui simplifient la vie des administrateurs.
La possibilité d'agrandir, de réduire des FS, de jouer avec les modes RAID et d'effectuer des "snapshots" de manière simple et au sein du même outil devrait apporter beaucoup plus de souplesse au niveau de l'administration.
Mais BTRFS n'est pas encore prêt pour passer en production et les outils en version 0.19 rappellent bien que ce système est encore en période de rodage !
Note 2016 : BTRFS est maintenant "adulte" et suffisamment stable pour la production.
Je vous propose toutefois quelques tests "pour voir".
Première approche de BTRFS
Première approche de BTRFS jppLe premier test est juste destiné à apprendre le fonctionnement basique des outils liés à BTRFS il a été executé sur des volumes LVM créés pour l'occasion avant de passer au travail sur des partitions physiques.
Mais, ATTENTION, la version des outils n'est (sur Debian unstable) encore que "0.19+20120328-1". Cela bouge mais la version "stable" 1.0 est peut-être encore assez loin.
Pour tester BTRFS il faut un noyau dont le support BTRFS est activé ! Si, comme c'est probable le support BTRFS est compilé en module un simple :
modprobe btrfs
devrait vous renseigner :
FATAL: Module btrfs.ko not found.
ou bien meilleur aucun message et un code retour 0.
Ce support devrait être actif pour les noyaux récents de la plupart des distributions, sinon compilez le vous même et installez le. Les tests sont réalisés avec un noyau très récent (3.4.4) afin de bénéficier des dernières corrections.
Ensuite il faut charger les outils BTRFS pour disposer, entre autres, de mkfs.btrfs. Sur Debian le paquet se nomme "btrfs-tools" sans autre complication et s'installe rapidement.
Pour ce premier test j'ai créé deux "disques" LVM de 20G nommés :
VOL_EXT4 et VOL_BTRFS. Le premier sera formaté classiquement en EXT4, le secon en BTRFS.
La commande "mkfs.btrfs" assure le formatage et la labellisation, ici :
date ; mkfs -t btrfs -L DISK_BTRFS /dev/mapper/TALE-VOL_BTRFS ; date
vendredi 4 mai 2012, 19:55:30 (UTC+0200)
WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using
fs created label DISK_BTRFS on /dev/mapper/TALE-VOL_BTRFS
nodesize 4096 leafsize 4096 sectorsize 4096 size 20.00GB
Btrfs Btrfs v0.19
vendredi 4 mai 2012, 19:55:30 (UTC+0200)
Le résultat est quasi instantané !
En EXT4 :
date; mkfs -t ext4 /dev/mapper/TALE-VOL_EXT4 ; date
vendredi 4 mai 2012, 19:56:52 (UTC+0200)
mke2fs 1.42.2 (9-Apr-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
1310720 inodes, 5242880 blocks
262144 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
160 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
vendredi 4 mai 2012, 19:56:54 (UTC+0200)
Deux secondes pour 20G, donc plus de trois minutes pour un disque de 2To. On monte ensuite les deux partitions et on vérifie :
df | grep mnt
/dev/mapper/TALE-VOL_EXT4 20907056 440692 19417788 3% /mnt/VOL_EXT4
/dev/mapper/TALE-VOL_BTRFS 20971520 120 18845632 1% /mnt/VOL_BTRFS
Tiens ETX4 consomme 3% ?
Tests "dd" en écriture, fichier de 8Go :
Pour EXT4 wait 37 .. 75% BO # 65000 .. 136000 (chiffres de "vmstat")
256000+0 records in
256000+0 records out
8388608000 bytes (8,4 GB) copied, 63,0721 s, 133 MB/s
Pour BTRFS wait 29.. 55% BO # 68000 .. 180000
256000+0 records in
256000+0 records out
8388608000 bytes (8,4 GB) copied, 60,2699 s, 139 MB/s
Tests "dd" en écriture, fichier de 16Go :
Pour EXT4 wait 37 .. 75% output # 65000 .. 136000
512000+0 records in
512000+0 records out
16777216000 bytes (17 GB) copied, 136,869 s, 123 MB/s
Pour BTRFS wait 29.. 55% output # 68000 .. 190000
512000+0 records in
512000+0 records out
16777216000 bytes (17 GB) copied, 123,338 s, 136 MB/s
La vitesse du BTRFS n'est que très peu supérieure mais les "wait_states" sont inférieurs (mesuré avec vmstat) mais reste plus constante pour les fichiers de 8G et 16G.
Tests "dd" en lecture, fichier de 16Go :
EXT4 :
512000+0 records in
512000+0 records out
16777216000 bytes (17 GB) copied, 125,661 s, 134 MB/s
BTRFS :
512000+0 records in
512000+0 records out
16777216000 bytes (17 GB) copied, 119,848 s, 140 MB/s
Léger avantage à BTRFS.
Aucune commande complexe n'a été utilisée ici, la seule différence est la pose du label de FS par "mkfs.btrf" qui simplifie un peu les commandes.
Les tests précédents ont étés réalisés avec un noyau "xenifié", ci-dessous le même test sur la même version de noyau (3.3.4) en mode "normal" :
Test "dd" en lecture fichier 16Go :
EXT4 :
512000+0 records in
512000+0 records out
16777216000 bytes (17 GB) copied, 108,485 s, 155 MB/s
BTRFS :
512000+0 records in
512000+0 records out
16777216000 bytes (17 GB) copied, 99,3723 s, 169 MB/s
Les résultats sont meilleurs laissant toujours un léger avantage à BTRFS.
J'ai prévu de présenter plus loin quelques possibilités attrayantes et les outils qui permettent d'y arriver. C'est tout pour aujourd'hui ... à la prochaine.
BTRFS : après quelques mois
BTRFS : après quelques mois jppAprès plusieurs mois d'usage BTRFS se comporte très bien.
J'ai eu un plantage (corruption) tout à fait au début mais les outils de réparation du FS ont fonctionné correctement bien que m'ayant rappelé avant lancement qu'ils n'etaient que des versions "beta" encore incomplètes.
Depuis je suis passé à des versions de noyau très récentes (3.5 et 3.6 maintenant) et je n'ai plus souffert d'un seul ennui. Je pense que le support BTRFS a été amené à maturité dans les dernières versions de noyau et qu'il est parfaitement envisageable de l'utiliser. J'ai d'ailleurs transféré tous mes répertoires personnels sur une partition RAID (/dev/mdx) formatée en BTRFS.
Au vu des sauvegardes que j'effectue régulièrement je n'ai pas vraiment testé les "snapshots" de BTRFS.
Note 2016 : pas d'ennuis avec les noyaux de la série 4.x.
Note 2024 : BTRFS est toujours là et fonctionne normalement avec un noyau 6.7.
RAID1 BTRFS et EXT4
RAID1 BTRFS et EXT4 jpp| Écriture | Lecture | |||
| P. 1 | P. 2 | P.1 | P.2 | |
| EXT4 | 53,6 | 49,1 | 120,0 | 111,0 |
| BTRFS | 67,1 | 66,1 | 103,0 | 102,0 |
| % BTRFS / EXT4 | +20,12% | +25,72% | -16,50% | -8,82% |
RAID1 BTRFS et dev/md
RAID1 BTRFS et dev/md jppCe dernier test doit permettre de mesurer toute la puissance et la souplesse de BTRFS car il va ici jouer deux rôles :
- gestion du RAID
- gestion du File system
permettant ainsi de n'utiliser qu'un outil au lieu des deux habituels (Device Mapper ou LVM pour le RAID, Gestionnaire de FS tel EXT3, EXT4 ...). Pour améliorer la fiabilité (et la rapidité ?) les deux disques sont sur deux contrôleurs différents. On utilisera le parametre "odirect" de "dd" pour limiter l'influence de la mémoire.
D'abord "casser" le RAID actuel, c'est super simple ...
mdadm -S /dev/md0 # stopper le device
mdadm --zero-superblock /dev/sde1 # effacer les traces
mdadm --zero-superblock /dev/sdd1 # sur les deux disques
Après cette petite opération il est de bon ton de redémarrer le système pour assurer une bonne reconnaissance des changements. effectués.
Sitôt dit, sitôt fait et on enchaîne sur la création de notre RAID1 BTRFS :
mkfs.btrfs -m raid1 -d raid1 -L BTRFS /dev/sdc1 /dev/sdd1
WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using
adding device /dev/sdd1 id 2
fs created label BTRFS on /dev/sdc1
nodesize 4096 leafsize 4096 sectorsize 4096 size 800.00GB
Btrfs Btrfs v0.19
On monte ce nouveau FS :
mount LABEL=BTRFS /mnt/DISK1omount LABEL=BTRFS /mnt/DISK1
et on vérifie :
df -k | grep mnt
/dev/sdc1 838860800 312 803151616 1% /mnt/DISK1
Seul le premier disque est visible et le FS est bien noté 800GB.
Un petit test "dd" en écriture :
dd if=/dev/zero of=/mnt/DISK1/test bs=32K count=1536000 conv=fsync oflag=direct
1536000+0 records in
1536000+0 records out
50331648000 bytes (50 GB) copied, 1001,96 s, 50,2 MB/s
Pendant ce temps les deux disques sont actifs, chacun sur leur contrôleur :
21:06:33 sdd 1577,00 0,00 100928,00 64,00 0,44 0,28 0,28 43,60
21:06:33 sde 1578,00 0,00 100992,00 64,00 0,75 0,48 0,47 74,80
Average: sdd 1577,00 0,00 100928,00 64,00 0,44 0,28 0,28 43,60
Average: sde 1578,00 0,00 100992,00 64,00 0,75 0,48 0,47 74,80
Pour corser un peu la comparaison je vais profiter de la partition "2" toujours en RAID-1 (Device Manager) pour la formater en BTRFS et comparer ainsi le RAID-1 BTRFS "pur" et le RAID-1 "DM" + BTRFS. La partition 2 étant un peu moins rapide du fait de sa position DM + BTRFS part avec un petit handicap (#5%).
Les résultats bruts :
RAID-1 BTRFS :
1536000+0 records in
1536000+0 records out
50331648000 bytes (50 GB) copied, 966,6 s, 52,1 MB/s
DM + BTRFS :
1536000+0 records in
1536000+0 records out
50331648000 bytes (50 GB) copied, 993,912 s, 50,6 MB/s
Au vu des chiffres on peut considérer qu'il y a égalité.
Passons à la lecture et afin de vérifier si les deux disques sont bien utilisés on va tester deux configurations :
DD avec l'option "idirect"
DD sans l'option "idirect"
RAID-1 BTRFS avec "idirect" :
dd if=/mnt/DISK1/test of=/dev/null bs=32K conv=fsync iflag=direct
1536000+0 enregistrements lus
1536000+0 enregistrements écrits
50331648000 octets (50 GB) copiés, 489,408 s, 103 MB/s
Sans "idirect" :
dd if=/mnt/DISK1/test of=/dev/null bs=32K conv=fsync
dd: fsync a échoué pour « /dev/null »: Argument invalide
1536000+0 enregistrements lus
1536000+0 enregistrements écrits
50331648000 octets (50 GB) copiés, 430,43 s, 117 MB/s
DM + BTRFS avec "idirect" :
dd if=/mnt/DISK2/test of=/dev/null bs=32K conv=fsync iflag=direct
1536000+0 enregistrements lus
1536000+0 enregistrements écrits
50331648000 octets (50 GB) copiés, 508,961 s, 98,9 MB/s
Sans idirect :
dd if=/mnt/DISK2/test of=/dev/null bs=32K conv=fsync
1536000+0 enregistrements lus
1536000+0 enregistrements écrits
50331648000 octets (50 GB) copiés, 380,004 s, 132 MB/s
Avec l'utilisation de "idirect" les deux possibilités sont à peu près à égalité. Par contre sans ce flag le couple "DM" + BTRFS est très loin devant ...
On refait le test en notant l'activité des différents disques sur une vingtaine de secondes :
RAID1 BTRFS
sar -pd 2 10 | egrep 'sdd|sde' | grep 'Average'
Average: sde 309,50 213753,60 0,00 690,64 9,64 31,16 3,12 96,68
Average: sdd 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
DM + BTRFS
Average: sde 187,60 140957,60 0,00 751,37 5,77 30,60 3,80 71,28
Average: sdd 163,10 109883,20 0,00 673,72 4,26 26,19 3,96 64,56
On remarque tout de suite que BTRFS n'utilise qu'un disque au cours de ce test alors que DM en utilise deux ce qui explique probablement la meilleure vitesse obtenue.
Remarque : lors d'un deuxième test BTRFS a utilisé l'autre disque il est donc probable que sur plusieurs IO simultanées il est capable de se servir des deux disques.
On vérifie avec deux "dd" en parallèle :
Average: sde 937,40 207295,20 0,00 221,14 28,18 29,98 1,06 99,60
Average: sdd 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Et bien non il se sert d'un seul disque ? Et avec deux fichiers différents que va-t-il se passer ?
On copie d'abord une partie de notre fichier de 50G :
RAID1 BTRFS
dd if=test_UN of=test_DX bs=32K count=512000
512000+0 records in
512000+0 records out
16777216000 bytes (17 GB) copied, 376,779 s, 44,5 MB/s
Pendant la copie un seul disque est utilisé en lecture et bien sûr les deux en écriture.
La vitesse est sensiblement moindre que lors des tests d'écriture seule 44,5 contre 52,1.
DM + BTRFS
dd if=test_UN of=test_DX bs=32K count=512000
512000+0 records in
512000+0 records out
16777216000 bytes (17 GB) copied, 339,194 s, 49,5 MB/s
Presque la vitesse en écriture seule 49,5 contre 50,6 ! Pendant la copie les deux disques sont utilisés en lecture et en écriture.
Le test avec deux fichiers
RAID1 BTRFS :
Un seul des deux disques est utilisé et le contrôleur est à 100%, le temps de WAIT est élevé (30 à 45%) le CPU utilisé est de l'ordre de 10% :
Average: sde 202,70 204479,60 0,00 1008,78 23,49 116,10 4,93 100,00
Average: sdd 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
Fichier 1 ;
512000+0 records in
512000+0 records out
16777216000 bytes (17 GB) copied, 319,734 s, 52,5 MB/s
Fichier 2 :
512000+0 records in
512000+0 records out
16777216000 bytes (17 GB) copied, 260,957 s, 64,3 MB/s
Soit un total d'environ 117Mo/seconde parfaitement égal au test précédent.
DM BTFRS
Les deux disques sont utilisés et les deux contrôleurs à 100%, le temps de WAIT est très élevé (40 à 60%), le cpu utilisé varie de 14 à 28% :
Average: sde 227,85 218987,20 0,00 961,10 13,08 57,72 4,39 100,00
Average: sdd 210,60 215552,00 0,00 1023,51 11,94 56,74 4,74 99,92
Fichier 1 :
512000+0 records in
512000+0 records out
16777216000 bytes (17 GB) copied, 99,329 s, 169 MB/s
Fichier 2 :
512000+0 records in
512000+0 records out
16777216000 bytes (17 GB) copied, 155,029 s, 108 MB/s
Soit un maximum de plus de 270 Mo/seconde ! J'ai refait le test en notant les vitesses moyennes de chaque disque (je rappelle que si les disques sont identiques ce n'est pas le cas des contrôleurs) :
Average: sde 214,20 219289,60 0,00 1023,76 11,50 53,70 4,66 99,78
Average: sdd 191,00 165808,40 0,00 868,11 9,27 48,44 5,02 95,92
Un des disques va nettement plus vite ! Lors de ce second essai j'ai obtenu 150 et 112Mo/seconde soit environ 260Mo/seconde, ce qui est en phase avec le premier essai.
En bref DM + BTRFS ça a l'air de déménager. Ce petit problème réglé je vais remettre la partition 1 en mode "DM".
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdd1 /dev/sde1
On reboote par précaution ... et on lance
mkfs -t btrfs -L BTRFS_1 /dev/md0
WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using
fs created label BTRFS_1 on /dev/md0
nodesize 4096 leafsize 4096 sectorsize 4096 size 399.87GB
Btrfs Btrfs v0.19
Et la synchronisation du raid commence :
md0 : active raid1 sdd1[0] sde1[1]
419299136 blocks super 1.2 [2/2] [UU]
[>....................] resync = 0.1% (515264/419299136) finish=67.7min speed=103052K/sec
Ces nouveaux disques de 2To semblent nettement plus rapides que les "anciens" disques de 750 Go (2 and déjà) déja présents dans la machine.
Ne pas oublier ensuite de positionner ce nouveau "raid" dans le fichier "/etc/..../mdadm.conf",
mdadm --examine --scan
est votre ami.
Il est toutefois à noter que j'ai eu quelques plantages système, crash complets sans possibilité de reprendre la main ou "ooops" déclenchant une violation de protection mémoire de "dd" et un crash lors de l'utilisation de "cp -dpR" pour recopier une arborescence complète.
Ces plantages ont eu lieu avec des noyaux < 3.3. Avec un noyau 3.3.5 les plantages ont été moins nombreux, j'ai depuis refait quelques tests avec un noyau 3.4-rc7 pendant lesquels je n'ai noté aucun ennui, les "cp -dpR" ont parfaitement fonctionné malgré les plus de 80Go à recopier (#500 000 répertoires et plus de 2 000 000 fichiers).
J'ai mis pour le moment mon répertoire personnel (que je sauvegarde souvent) sur une partition en RAID1 DM+BTRFS. Les résultats sont pour le moment excellents, l'affichage de photos me semble beaucoup plus rapide qu'avant malgré les 15 à 19Mo de chaque photo.
Un autre test fait sur mon répertoire HOME (maintenant en BTRFS) recopié pour sauvegarde dans une baie externe :
Environ 16 Go avec #5700 répertoires et #57000 fichiers (Pas mal de fichiers photo RAW et JPG de 10 à 15Mo chacun) en un peu moins de 4 minutes soit une vitesse moyenne de # 66Mo/seconde comprenant donc lecture sur BTRFS et écriture sur une partition LVM de la baie.
Ainsi la copie de sauvegarde devient (presque) un plaisir.
Passer en RAID 1
Passer en RAID 1 jppNote : le système est un Debian "Jessie" mais la plupart des remarques peuvent s'appliquer à d'autres distributions.
Sur la machine qui me sert de frontal Internet j'ai eu de multiples alertes "Smart" me signalant des dégradations sur des "seek..." et quelques autres anomalies. Ces disques sont assez anciens et très sollicités car la machine fonctionne 24/24 et héberge plusieurs services : mail, DNS, DHCP, serveur Apache, agent centralisateur de collectd, une base Mysql ainsi que Suricata et Snorby. Les deux disques de cette machine (500Go) deviennent par ailleurs un peu petits. Ils sont montés en LVM, chaque volume LVM est mirroré, mais c'est un peu lourd à gérer. Le système est sur un petit SSD que je sauvegarde régulièrement.
J'ai donc décidé de changer les disques et de mettre deux disques en RAID1 sur lesquels je mettrais trois partitions, dont deux avec LVM, plus un swap. Il ne faut pas oublier de charger le paquet "mdadm" pour disposer des outils adéquats.
Comme le contrôleur supporte 4 disques j'ai pu monter un des futurs disques en plus afin de :
- Le partitionner :
- une partition pour le système,
- une pour les disques des machines virtuelles,
- une pour le stockage des données
- une de swap.
Ensuite :
- Créer le Raid1 avec une seule patte.
- Créer les PV pour LVM sur les partitions 2 et 3
- Charger les données, du système et copier les images de machines virtuelles.
Pour ceci il est nécessaire de stopper le maximum de services afin de ne pas se compliquer la tâche.
Ne pas oublier de mettre les partitions en type "Linux RAID" dans fdisk (type "fd") :
Command (m for help): t
Partition number (1-4, default 4): 1
Partition type (type L to list all types): 21
Changed type of partition 'Linux RAID' to 'Linux RAID'.
... idem pour les autres partitions.
On arrive alors à ceci dans fdisk :
Disk /dev/sdc: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 48D952DA-AF21-46D3-BB36-73DFFF32A96A
Device Start End Sectors Size Type
/dev/sdd1 2048 536872959 536870912 256G Linux RAID
/dev/sdd2 536872960 1073743871 536870912 256G Linux RAID
/dev/sdd3 1073743872 1912604671 838860800 400G Linux RAID
/dev/sdd4 1912604672 1953525134 40920463 19,5G Linux RAID
Ensuite il faut créer nos "RAID" en mettant à chacun un disque physique et un disque "missing" :
mdadm --create /dev/md2 --level=1 --raid-disks=2 missing /dev/sdd1
....
Puis enregistrer la config de nos RAID pour qu'ils soient reconnus au boot avec :
mdadm --examine --scan >>/etc/mdadm/mdadm.conf
Vous pouvez ensuite modifier dans ce fichier l'adresse mail de destination des messages.
Il est prudent de redémarrer la machine pour vérifier que nos RAID sont bien accrochés et se retrouvent après redémarrage.
On arrive alors a "voir" l'état de nos RAID en exécutant :
cat /proc/mdstat
Personalities : [raid1]
md3 : active raid1 sdc2[1]
268304384 blocks super 1.2 [2/1] [_U]
bitmap: 1/2 pages [4KB], 65536KB chunk
md4 : active raid1 sdc3[1]
419299328 blocks super 1.2 [2/1] [_U]
bitmap: 1/4 pages [4KB], 65536KB chunk
md5 : active raid1 sdc4[1]
20443840 blocks super 1.2 [2/1] [_U]
md2 : active raid1 sdc1[1]
268304384 blocks super 1.2 [2/1] [_U]
bitmap: 2/2 pages [8KB], 65536KB chunk
unused devices: <none>
-------------------------------------------------------
Le système signale par ailleurs dans les logs lors du démarrage que les RAID ne sont pas en bon état :
Nov 25 13:24:49 xxxxxx systemd-fsck[408]: /dev/md2 : propre, 17129/16769024 fichiers, 10491322/67076096 blocs
Nov 25 13:24:49 xxxxxx systemd-fsck[516]: BOOT : propre, 326/1222992 fichiers, 139566/4882432 blocs
Nov 25 13:24:49 xxxxxx mdadm-raid[196]: Assembling MD array md2...done (degraded [1/2]).
et mdadm-raid vous envoie régulièrement des mails tels que :
This is an automatically generated mail message from mdadm
running on xxxxxx.xxx.xxx
A DegradedArray event had been detected on md device /dev/md/4.
Faithfully yours, etc.
P.S. The /proc/mdstat file currently contains the following:
Personalities : [raid1]
md4 : active raid1 sdc3[1]
419299328 blocks super 1.2 [2/1] [_U]
bitmap: 1/4 pages [4KB], 65536KB chunk
md5 : active raid1 sdc4[1]
20443840 blocks super 1.2 [2/1] [_U]
.......
-------------------------------------------------------
On peut alors :
Formater la première partition en ext4
Recopier les répertoires système du vieux disque, /var, quelques morceaux de /usr ... sur la première partition, "cp -dpRx" est votre ami.
Créer le PV LVM sur la deuxième partition puis créer les volumes logiques destinés à mes machines virtuelles (je ne le fais pas à la main mais avec "kvpm" que j'aime bien).
Stopper les machines virtuelles et copier leurs images disque, bêtement avec :
"dd if=ancien of=nouveau bs=65536" et cela marche très bien.
J'ai ensuite modifié le fichier /etc/fstab" pour monter les "nouvelles" partitions à la place des "anciennes", les anciennes sont toujours là (au cas ou ?).
Modifié les scripts de lancement des MV pour utiliser les nouveaux volumes et redémarré.
Super, tout se passe bien, le système est OK, les MV ont bien démarré et leurs services sont accessibles. Je vais pouvoir démonter les anciens disques.
Je stoppe encore la machine, démonte les anciens disques et je les stocke dans un coin tranquille (encore au cas ou) et monte le nouveau disque encore vierge.
Il fait alors recommencer le partitionnement de ce nouveau disque, sans oublier de mettre le type de partition à "Linux RAID".
Faire gaffe au nom des disques, car le démontage des anciens disques décale tout. On arrive presque à la fin on va, enfin, créer un vrai RAID1 avec deux disques :
mdadm --manage /dev/md2 --add /dev/sdb1
cat /proc/mdstat
Personalities : [raid1]
md3 : active raid1 sdc2[1]
268304384 blocks super 1.2 [2/1] [_U]
bitmap: 1/2 pages [4KB], 65536KB chunk
md4 : active raid1 sdc3[1]
419299328 blocks super 1.2 [2/1] [_U]
bitmap: 1/4 pages [4KB], 65536KB chunk
md5 : active raid1 sdc4[1]
20443840 blocks super 1.2 [2/1] [_U]
md2 : active raid1 sdb1[2] sdc1[1]
268304384 blocks super 1.2 [2/1] [_U]
[>....................] recovery = 0.2% (781056/268304384) finish=28.5min speed=156211K/sec
bitmap: 2/2 pages [8KB], 65536KB chunk
La synchronisation de la première partie du RAID /dev/md2 est commencée et prévue pour un peu moins de 30 minutes, ne pas être pressé et éviter le café car il y a d'autres RAID à compléter.
La vitesse de construction varie un peu mais reste supérieure à 100000K/sec mais la première partition fait 256G, la plus grosse 400G ce qui va durer une éternité.
La première partition contient beaucoup de fichiers "actifs", par exemple tous les logs, la base de données mysql .... cela devrait augmenter le temps de construction. Mais, un peu plus tard : :
md2 : active raid1 sdb1[2] sdc1[1]
268304384 blocks super 1.2 [2/1] [_U]
[================>....] recovery = 84.4% (226534144/268304384) finish=6.7min speed=103609K/sec
bitmap: 2/2 pages [8KB], 65536KB chunk
Ca s'approche de la fin .... toujours à un peu plus de 100MO/seconde. Au passage "iotop" ne voit rien et affiche des chiffres "ridicules".
Nov 25 19:16:52 xxxxxx kernel: [ 939.531841] md: recovery of RAID array md2
Nov 25 19:59:28 xxxxxx kernel: [ 3493.885198] md: md2: recovery done.
43 minutes environ au lieu des #30 annoncées.
Pour la partition suivante il y a deux disques de machines virtuelles, je ne vais pas les stopper avant de commencer la construction du RAID pour environ 30 minutes annoncées.
Nov 25 20:34:04 xxxxxx kernel: [ 5569.372170] md: recovery of RAID array md3
Nov 25 21:24:56 xxxxxx kernel: [ 8618.957262] md: md3: recovery done.
Soit environ 50 minutes.
J'aurais mieux fait de stopper les MV car l'une d'elle a eu un problème lors du redémarrage (fsck manuel obligatoire).
Passons à la partition de 400G.
mdadm --manage /dev/md4 --add /dev/sdb3
mdadm: added /dev/sdb3
date
mercredi 25 novembre 2015, 21:28:55 (UTC+0100)
Et quelques instants plus tard :
cat /proc/mdstat
Personalities : [raid1]
md4 : active raid1 sdb3[2] sdc3[1]
419299328 blocks super 1.2 [2/1] [_U]
[=>...................] recovery = 6.5% (27293696/419299328) finish=95.4min speed=68420K/sec
bitmap: 0/4 pages [0KB], 65536KB chunk
La vitesse n'est "que" de 68Mo/seconde ? On doit approcher le milieu du disque ???
Beaucoup plus tard ... :
cat /proc/mdstat
Personalities : [raid1]
md4 : active raid1 sdb3[2] sdc3[1]
419299328 blocks super 1.2 [2/1] [_U]
[=======>.............] recovery = 36.8% (154667968/419299328) finish=70.2min speed=62746K/sec
bitmap: 0/4 pages [0KB], 65536KB chunk
date
mercredi 25 novembre 2015, 22:05:02 (UTC+0100)
En 37 minutes le temps restant n'a que diminué de 25 minutes .... que dire du résidu de 70 minutes ? Ensuite en 20 minutes le temps restant a diminué de 15 minutes.
A 22:40 ( durée 72 minutes) il reste encore 36 minutes ....
cat /proc/mdstat ; date
Personalities : [raid1]
md4 : active raid1 sdb3[2] sdc3[1]
419299328 blocks super 1.2 [2/1] [_U]
[=================>...] recovery = 89.9% (377065408/419299328) finish=13.5min speed=52082K/sec
bitmap: 0/4 pages [0KB], 65536KB chunk
mercredi 25 novembre 2015, 23:09:29 (UTC+0100)
Les 100 minutes sont atteintes il n'en reste plus que 13,5 mais la vitesse est tombée à 52MO/seconde. Pour finir :
Nov 25 21:28:53 xxxxxx kernel: [ 8856.327974] md: recovery of RAID array md4
Nov 25 23:24:41 xxxxxx kernel: [15800.532184] md: md4: recovery done.
1h56 minutes soit 116 minutes, heureusement que je n'ai pas utilisé des disques de 3To !
La dernière partition (futur SWAP) ne fait que 19G, cela devrait aller vite :
md5 : active raid1 sdb4[2] sdc4[1]
20443840 blocks super 1.2 [2/1] [_U]
[>....................] recovery = 1.5% (311040/20443840) finish=9.7min speed=34560K/sec
Par contre même pas 35MO/seconde ! Cette partie du disque est vraiment moins performante, mais après quelques minutes on monte à environ 45Mo/seconde ce qui est déjà un peu mieux.
Enfin, c'est fini !
La machine est sauvée et n'aura peut-être pas d'incident disques avant quelques années ... je croise les doigts.
SSD et machines virtuelles
SSD et machines virtuelles jppAyant eu l'occasion de me procurer deux SSD de 512Go j'ai rapidement décidé de les utiliser pour fournir l'espace disque à quelques machines virtuelles.
Installation précédente :
- Deux disques Hitachi Deskstar de 3To montés en miroir (DMRAID) avec deux Volume Group LVM.
Nouvelle installation :
- Deux disques Samsung SSD 850 PRO 512GB montés en miroir (DMRAID) avec deux VG LVM.
Les deux nouveaux disques sont utilisés comme support d'un Volume Group LVM dans lequel j'ai pu "tailler" l'espace nécessaire à quelques machine virtuelles et d'un autre dédié à une base Mysql de quelques Go utilisées sur le système hôte et il y reste encore un peu de place.
La différence est très sensible sur les temps de réponse de la base Mysql : de gros "select count(*) from ..." sont passés de plus d'environ deux minutes à une trentaine de secondes, soit approximativement une performance quatre fois meilleure, comme mesuré dans l'article indiqué ci-dessous.
Pour les machines virtuelles la différence est également importante, le serveur Web, sur lequel sont installées ces pages assure un temps de réponse bien meilleur et les statistiques apparaissent bien plus rapidement, décidément Mysql aime les SSD et le montre bien. (Voir article Mysql et SSD). Quand à l'interface d'administration de Drupal il est devenu agréable à utiliser, pratiquement plus d'attente entre les pages.
Une des MV est un serveur de mail Zimbra dont l'interface d'administration fournit des statistiques diverses dont une sur l'usage CPU. Une des statistiques m'a particulièrement intéressé, celle des IOWait qui est très significative. 
On voit bien la baisse des Cpu_iowait lors du redémarrage de la machine.
Le ressenti de l'interface Webmail est meilleur la réponse plus franche et plus rapide.
En bref : les SSD c'est le pied.
Mysql : SSD / HD
Mysql : SSD / HD jppUn petit graphe des IO pour les deux machines : 
SSD
Encore un test SSD/HDD ? J'ai récemment installé une base volumineuse sur une machine munie de SSD et j'ai constaté que les temps de réponse étaient excellents. Afin de quantifier le phénomène j'ai installé la même base sur deux machines différentes (#90 millions de rangs dans la table principale) :
Machine 1 :
Core I7 6700 à 3.4 Mhz
RAM : 16Go
Base sur une partition dédiée d'un ensemble Raid1 sur HDD classique.
Mysql 5.7.22 Inno_buffers en mémoire classique
Machine 2 :
Core I5 7500 à 3.4 Mhz
Raml : 16Go
Mysql 5.7.22 Inno_buffers en mémoire "huge pages"
Base sur une partition dédiée d'un ensemble Raid1 sur SSD.
Les deux machines sont donc à peu près équivalentes en vitesse au point de vue des CPU puisque Mysql n'utilise qu'un CPU par requête et que le paramétrage de Mysql est identique sur les deux systèmes. Seule différence la machine 2 utilise des "huge pages" pour les buffers InnoDB.
Le premier test consiste à :
- Récupérer dans une table temporaire des rangs présents sur une autre machine par l'intermédiaire d'une table "federated".
- Insérer ces rangs dans une table permanente.
Test 1.
Machine 1 :
Récupérer 206020 rangs 11.48 sec
Insérer dans table "réelle" 69.70 sec
Machine 2 :
Récupérer 212290 rangs 5,42 sec
Insérer dans table "réelle" 11,92 sec
Test 2.
Machine 1 :
Récupérer 2495 rangs 4,76 sec
Insérer dans table "réelle" 1,87 sec
Machine 2 :
Récupérer 2482 rangs 0,32 sec
Insérer dans table "réelle" 0,12 sec
Test 3.
Machine 1 :
Récupérer 2495 rangs 9,66 sec
Insérer dans table "réelle" 57,04 sec
Machine 2 :
Récupérer 2482 rangs 2,22 sec
Insérer dans table "réelle" 7.85 sec
Après quelques autres tests le tableau récapitulatif : 
Au final la base sur SSD effectue les opérations presque 5,7 fois plus rapidement.
Tableau à partir des mêmes données mais en rangs traités par seconde : 
Pour l'insertion le SSD semble moins "bon" mais cette phase comprends la lecture sur la machine origine et le transfert par le réseau qui sont probablement égaux pour les deux machines.
Deuxième test : compter les rangs de la plus grosse table.
Pour ce test :
- On redémarre Mysql pour bien vider les caches
- On exécute deux comptages successifs (# 90 millions de rangs).
Machine 1 :
Premier comptage : 48,36 sec
Comptage suivant : 22,65 sec
Machine 2 :
Premier comptage : 22,07 sec
Comptage suivant : 19,44 sec
Même test le lendemain après ajout de #133000 rangs pour un total de 91176892
Machine 1 :
Premier comptage : 52,24 sec
Comptage suivant : 22,61 sec
Machine 2 :
Premier comptage : 21,91 sec
Comptage suivant : 19,59 sec
La différence est moins importante mais le SSD gagne quand même par plus de 2 à 1 sur le comptage "brut". On constate quand même la bonne efficacité des caches.
iotop montre de la lecture a #30 Mo/sec pour les HDD et > 60Mo/sec pour les SSD.
Le deuxième comptage est visiblement effectué sur les caches (peu ou pas d'IO visibles), la différence d'environ 10% est très probablement due à l'usage des "huge pages" pour le cache InnoDB de la machine 2 (large-pages pour Mysql).
Un petit graphe des IO pour les deux machines : 
Petite bizarrerie au démarrage pour le SSD qui met #7 secondes pour arriver à son plein régime ?
La même remarque s'applique à plusieurs tests.
On peut voir par ailleurs que les temps de comptage sur la machine SSD sont très peu différents entre le premier comptage (avec accès disque) et le suivant réalisé immédiatement (ne montrant pas d'IO), les disques SSD ne semblent quasiment pas ralentir le traitement (#10% de différence seulement) par rapport au traitement depuis le cache.
Troisième test : créer un nouvel index.
L'index est composé de trois champs.
Machine 1 : 23 min 42,63 sec
Machine 2 : 5 min 29,11 sec
Le rapport de durée est d'environ 4,3.
Pendant l'exécution j'ai vu plus de 240Mo/seconde en lecture sur les SSD contre un peu plus de 60Mo/seconde pour les HDD.
Mysql : SSD or not SSD
Mysql : SSD or not SSD jppAfin de mesurer un peu l'influence des disques sur une base Mysql j'ai effectué quelques petits tests par rapport à une base de référence installée sur des disques « classiques » 7200 tours.
Les test réalisés :
- Sur la machine d'origine (Core I5 à 3.4GHz, disques « classiques »), Mysql 5.6.30
- Sur une autre machine (Corei3 à 3.5GHz, tout SSD) le test est réalisé avec une installation « standard » de Mysql (5.6.30). Donc tout sur le disque système (/var/lib/mysql et /var/log/mysql)
- Toujours sur la machine SSD (5.6.30) avec une installation un peu plus optimisée :
- Logiciel sur le SSD système
- Données sur un SSD « DATA » (/var/lib/mysql)
- Logs sur un autre SSD « LOG » (/var/log/mysql + tmpdir)
- Le dernier test est réalisé sur la configuration « optimisée » avec la version 5.7.16
La base n'est pas énorme et comporte deux tables principales de # 10 millions et #100000 rangs et "tient" dans # 4Go.
Les résultats sont assez parlants, le passage sur SSD apporte une très nette amélioration de performance et pourtant le SSD supportant le système est un "vieux" modèle qui n'est pas au niveau des derniers modèles.
Voir un autre test sur le même sujet.
| N° TEST | 5.6.30 secondes (REF) | 5.6.30 SSD % Gain sur REF | 5.6.30 Opt. % Gain sur REF | 5.7.16 Opt. % Gain sur REF |
| TEST A | 1,00 | 0,00% | 0,00% | 0,00% |
| TEST B | 3,09 | 38,51% | 80,91% | 82,85% |
| TEST C | 1,45 | 61,38% | 74,48% | 74,48% |
| TEST D | 0,93 | 52,69% | 80,65% | 86,02% |
| TEST E | 5,96 | 5,70% | -0,67% | 5,54% |
| TEST F | 41,30 | 21,57% | 57,97% | 65,86% |
| TEST G | 13,68 | 74,12% | 89,40% | 94,88% |
| TEST H | 26,04 | 88,86% | 92,47% | 92,70% |
| TOTAL | 93,45 | 48,26% | 69,06% | 73,93% |
Et en image cela donne :
|
Dernier test : comptage sur une "grosse" table :
Machine SSD :
+-----------+
| count(*) |
+-----------+
| 134071332 |
+-----------+
1 row in set (50,52 sec)
Machine HDD :
+-----------+
| count(*) |
+-----------+
| 134072138 |
+-----------+
1 row in set (4 min 9,46 sec)
Environ 5/1 en faveur du SSD.