La lecture en ligne est gratuite
Le téléchargement nécessite un accès à la bibliothèque YouScribe
Tout savoir sur nos offres
Télécharger Lire

Comment évaluer les performances des fonctions de stockage ...

10 pages
Comment évaluer les performances des
fonctions de stockage d'un système ?
http://www.linux-france.org/~platu/weblog/
Voilà bien un sujet piège ! À l'occasion du renouvellement de sujets de travaux pratiques, j'ai essayé de proposer une
démarche la plus honnête possible et compatible avec le temps des séances de travaux pratiques. L'évaluation des
performances (ou benchmarking) d'un système est un sujet qui comporte tellement de biais, qu'il n'est pas évident
d'en faire une présentation simple et surtout satisfaisante. L'objet de ce billet est de présenter ouvertement l'état
«intermédiaire» de mes réflexions et les déclinaisons que j'ai pu trouver au niveau enseignement. Bien entendu, je suis
ouvert à toutes les propositions !?
Table des matières
1. Le contexte ............................................................................................................................................ 1
2. La méthodologie ..................................................................................................................................... 1
3. Le choix des outils .................................................................................................................................. 2
3.1. La suite Phoronix ......................................................................................................................... 2
3.2. Les méta-données avec fdtree ......................................................................................... ...
Voir plus Voir moins
Comment évaluer les performances des fonctions de stockage d'un système ? http://www.linux-france.org/~platu/weblog/
Voilà bien un sujet piège ! À l'occasion du renouvellement de sujets de travaux pratiques, j'ai essayé de proposer une démarche la plus honnête possible et compatible avec le temps des séances de travaux pratiques. L'évaluation des performances (ou benchmarking) d'un système est un sujet qui comporte tellement de biais, qu'il n'est pas évident d'en faire une présentation simple et surtout satisfaisante. L'objet de ce billet est de présenter ouvertement l'état «intermédiaire» de mes réflexions et les déclinaisons que j'ai pu trouver au niveau enseignement. Bien entendu, je suis ouvert à toutes les propositions !?
Table des matières
1. Le contexte ............................................................................................................................................ 1 2. La méthodologie ..................................................................................................................................... 1 3. Le choix des outils .................................................................................................................................. 2 3.1. La suite Phoronix ......................................................................................................................... 2 3.2. Les méta-données avec fdtree ........................................................................................................ 3 3.3. Les systèmes de fichiers avec iozone ............................................................................................... 3 4. Les échantillons ...................................................................................................................................... 4 4.1. Configuration du système hôte ....................................................................................................... 4 4.2. Configuration du système virtuel .................................................................................................... 5 4.3. Les macro-benchmarks phoronix ..................................................................................................... 7 4.4. Le micro-benchmark fdtree ............................................................................................................ 8 4.5. Le micro-benchmark iozone ........................................................................................................... 9 5. La conclusion ....................................................................................................................................... 10
1. Le contexte
Le «train» de la virtualisation entraîne avec lui des évolutions importantes aux niveaux réseau et stockage, Au delà des frontières technologiques, les découpages métier sont en train de bouger rapidement. Le temps où les «gens du système» et les «gens du réseau» s'ignoraient cordialement peut être considéré comme révolu.
On observe actuellement des mouvements que l'on peut comparer à ceux d'un ascenseur. Dans un sens, la virtualisation de plusieurs instances de systèmes d'exploitation sur un même système hôte a littéralement aspiré la commutation réseau au sein de ce système hôte. Dans l'autre sens, les besoins de mobilité et de réplication du stockage des données ont provoqué la dispersion des fonctions de stockage à travers le réseau.
Dans un tel contexte, comment évaluer correctement les performances entre des systèmes aux caractéristiques aussi diverses ? Bien avant l'avènement des fonctions de virtualisation, le sujet était déjà très polémique. L'expression consacrée, librement traduite de l'anglais, est toujours aussi éloquente ‐ «Au début il y a eu des mensonges, puis de sacrés mensonges et enfin desbenchmarks».
Interrogation supplémentaire, comment sensibiliser les étudiants à une démarche d'évaluation des performances d'une solution de stockage sans ajouter un mensonge de plus ? Il est facile de tenir des propos péremptoires et définitifs sur le thème ‐ «Les constructeurs, tous des menteurs». Il est autrement plus délicat de faire passer une méthode d'évaluation suffisamment rigoureuse.
1 Tout d'abord, j'ai commencé par réaliser une présentation baptiséeStockage réseau. L'objectif de ce support de cours est de présenter les acronymes DAS, NAS et SAN, d'introduire la distinction entre les accès en mode blocs et en mode fichier, puis de donner quelques pistes sur les contraintes et les solutions en matière de réplication.
Ensuite, j'ai cherché à illustrer les notions sur le stockage avec des travaux pratiques à base de logiciel libre. Logiquement, j'ai pensé à une séance destinée à présenter les accès en mode bloc en utilisant iSCSI et une autre séance pour présenter les accès en mode fichier en utilisant NFS.
Il restait à trouver une méthodologie d'évaluation des performances commune aux deux séances qui permette aux étudiants un début d'analyse critique sur les avantages et inconvénients des solutions présentées. C'est à ce niveau que les difficultés commencent.
2. La méthodologie
Après de nombreuses recherches, j'ai fini par trouver un article du sitehttp://fsbench.filesystems.org/intituléNotes on a 2 Nine Year Study of File System and Storage Benchmarkingqui résume bien les limites de l'exercice. L'étude en question porte sur 415benchmarks et 106 publications. L'article met en évidence les nombreux défauts présents dans tous les documents étudiés.
Au niveau le plus général, il faut considérer le fait que les systèmes de fichiers et de stockage ont des propriétés particulières qui les distinguent des autres éléments du système. Il est d'autant plus difficile d'analyser le comportement d'un système que les interactions sont complexes entre les dispositifs d'entrée-sortie, les caches, les démons et les autres composants du noyau. D'autres facteurs de complexité viennent s'ajouter comme les optimisations et les différentes nature de charge de travail réelles.
1 http://www.linux-france.org/prj/inetdoc/articles/stockage/ 2 http://www.fsl.cs.sunysb.edu/docs/fsbench/fsbench.pdf
1
Comment évaluer les performances des fonctions de stockage d'un système ?
La question de la reproduction d'une charge de travail utile sur une infrastructure de stockage est un problème à part entière. Si on ne peut pas se contenter de suites d'écritures ou de lectures séquentielles, une distribution totalement aléatoire des écritures et des lectures ne correspondra pas vraiment au profil du trafic généré par de véritables utilisateurs.
Dans une situation idéale, pour exploiter correctement les résultats d'un banc d'essai, le lecteur devrait être capable de vérifier les résultats et comparer les performances entre systèmes. Un certain nombre de critères sont énoncés dans l'article pour s'approcher de cet objectif.
Détailler la configuration de test. Il est important de préciser la configuration matérielle utilisée pour réaliser les tests de performances. Récemment, on a vu apparaître de nombreux chiffres indiquant des performances quasi identiques entre un stockage DAS utilisant la technologie SAS et un stockage SAN utilisant la technologie iSCSI. Les mesures en question peuvent paraître très suspectes si on ne prend pas en compte le fait que la connexion réseau de la baie de stockage iSCSI utilise une agrégation de 4 liens Gigabit Ethernet qui permettent d'atteindre le débit d'une connexion physique SAS à 3 Gigabits par seconde.
Préciser les objectifs du banc d'essai.. On doit pouvoir identifier facilement les motivations qui déterminent les conditions des tests de performances. Entre une solution de stockage destinée à l'hébergement du courrier électronique (fichiers de taille réduite) et solution dédiée au stockage d'un gestionnaire de bases de données (fichiers de taille importante), les conditions d'évaluation des performances diffèrent du tout au tout.
Indiquer la durée des tests effectués. Pour être significatifs, les résultats doivent durer plus de quelques minutes et être répétés plusieurs fois. Si les exécutions multiples d'un test produisent des résultats différents, des éléments statistiques précis doivent aussi être fournis.
Dans l'article cité en référence, les auteurs distinguent trois catégories debenchmarks.
LesMacro-Benchmarksutilisent plusieurs types d'opérations de nature différente et permettent d'obtenir une vue globale des performances d'un système. C'est dans cette catégorie que l'on trouve les mesures de temps de compilation. Le principal défaut de ce style de mesure apparaît assez facilement. Est-ce que le temps de compilation du noyau Linux est représentatif de la charge utile générée par les utilisateurs du système ? On peut en douter. Dans le contexte du stockage, le fait d'effectuer des opérations qui consomment le maximum des ressources des processeurs peut masquer le temps consacré par le système à la gestion des systèmes de fichiers (overhead).
Les testsTrace-basedbasés sur la répétition d'un trafic réel enregistré. Relativement à la catégorie précédente, sont l'intérêt de ce genre d'évaluation est évident, on cherche à se rapprocher le plus possible d'une charge utile correspondant aux véritables conditions d'exploitation de la solution de stockage. L'objectif est aussi d'obtenir une vue globale des performances. Quatre défauts importants sont identifiés avec cette technique la méthode de capture, la technique de répétition, la validité de la capture et sa disponibilité. Côté méthode de capture, suivant la couche du système d'exploitation utilisée pour la capture, on introduit un biais dans l'évaluation. Par exemple, si la capture est effectuée au niveau du système de fichiers ou au niveau des appels système, on pourra distinguer les opérations qui ont été servies ou non par le cache. Les trois autres défauts dépendent beaucoup de la solution utilisée pour répéter le profil de charge sur le système à évaluer.
LesMicro-Benchmarkslimitent à un ou deux types d'opérations. Ils sont utiles pour mesurer les caractéristiques se d'éléments spécifiques d'un système. Ces tests présentent un intérêt s'ils sont accompagnés d'autres tests appartenant aux autres catégories ; notamment deMacro-Benchmarks.
Une fois la terminologie posée, il faut faire des choix dans le catalogue des outils disponibles. Ce qui ne manquera pas d'introduire de nouveaux biais.
3. Le choix des outils
Comme indiqué ci-dessus dans la section consacrée aucontexte, le choix des outils d'évaluation des performances doit être compatible avec les enseignements de travaux pratiques. La contrainte principale qui apparaît immédiatement est le temps d'exécution des tests.
3.1. La suite Phoronix
3 La suite produite par le sitePhoronix tend à devenir un standard de fait dans le monde du logiciel libre. Cette suite permet d'exécuter des outils appartenant aux catégoriesMacro-BenchmarksetMicro-Benchmarks. Les résultats produits répondent plutôt correctement aux critères énoncés dans la section précédente. Par exemple, les résultats du testFS-4 Mark 3.3sur le transportable M6300 se présentent de la façon suivante sur le sitePhoronix Global. La description de la configuration système ne mentionne pas l'utilisation du gestionnaire de volume logique LVM. C'est le défaut de cette page le plus facile a identifier.
La suitePhoronixest disponible sous forme de paquet (Debian|Ubuntu) à l'adressehttp://www.phoronix-test-suite.com/.
L'installation initiale ne demande que deux étapes une fois le paquet téléchargé individuellement à partir du répertoire courant.
# dpkg -i phoronix-test-suite_2.4.1_all.deb # apt-get -f install
L'utilisation de la suite peut se faire au niveau utilisateur sauf lorsque le test à exécuter nécessite l'installation d'un nouveau paquet bien sûr.
Dans la catégorieMacro-Benchmarks, les suitesdisk,compilation,compressionetcomputationalrépondent bien au critère sur la mise en œuvre d'opérations de nature différente. Pour autant, même si les opérations effectuées sont variées, elles ne correspondent pas vraiment au profil d'une activité utilisteur.
La catégorieMicro-Benchmarksest très étoffée et on y retrouve pratiquement tous les outils classiques.
3 http://www.phoronix.com 4 http://global.phoronix-test-suite.com/?k=profile&u=phil-2482-230-17935
2
Comment évaluer les performances des fonctions de stockage d'un système ?
Pour visualiser les listes des tests et des suites, il suffit de faire appel aux commandes$phoronix-test-suite list-tests et$phoronix-test-suite list-suites.
3.2. Les méta-données avec fdtree
Si les outils d'évaluation au niveau système sont nombreux, il n'en va pas de même pour les tests de type méta-données mettant en œuvre les commandes usuelles du Shell. J'ai trouvé un article particulièrement intéressant à ce sujet sur le 5 6 siteLINUX Magazine. Il est intituléMetadata Performance of Four Linux File Systems. L'outil de typeMicro-Benchmark 7 utilisé dans l'article est appeléfdtreeest lui même un Shell script. Les tests effectués sont basés sur quatre opérations. Ce script utilise la récursivité ; ce qui permet de répartir les appels de commandes entre les cœurs disponibles sur le processeur.
• Création de répertoire
• Création de fichier
• Effacement de fichier
• Effacement de répertoire
À priori, ce genre de test doit être intéressant pour caractériser l'impact des transactions réseau dans les accès aux systèmes de fichiers distants qu'il s'agisse du mode bloc ou du mode fichier. Je verrai à l'issue des séries de travaux pratiques si l'évaluation des performances des méta-données présente un intérêt.
3.3. Les systèmes de fichiers avec iozone
8 AvecIOzone en entre vraiment dans la catégorieMicro-Benchmark, puisque cet outil est destiné à évaluer les performances des systèmes de fichiers et non du système dans son ensemble. IOzone offre des options originales puisqu'il mesure les accès aux données en écriture et en lecture avec répétition des opérations.
Les définitions des opérations évaluées en lecture sont les suivantes :
Read, Lecture Lecture complète d'un fichier existant enregistrement par enregistrement.
Re-read, Relecture Relecture d'un fichier récemment lu. Le but de cette opération est de caractériser l'effet de l'utilisation du cache propre au système de fichiers. Les optimisations usuelles des systèmes de fichiers au sein du noyau maintiennent des blocs d'un fichier lu en cache. Si ce type de cache est en œuvre, les performances en relecture doivent être meilleures.
Random Read, Lecture aléatoire Lecture d'un fichier unique avec des accès aléatoires enregistrement par enregistrement dans le fichier. Les lectures s'arrêtent dès que le nombre d'enregistrements lu atteint la taille du fichier. Le but de cette opération est de caractériser l'effet de l'utilisation, entre autres, du ou des caches du système d'exploitation, du nombre de disques utilisés, des temps de latence des accès disque et du cache disque.
Backward Read, Lecture à rebours Lecture d'un fichier à rebours. Il existe de nombreuses applications, notamment scientifiques, qui utilisent cette méthode d'accès. De même, certains systèmes de fichiers détectent ces accès et améliorent les performances correspondantes. Ici, le pointeur de fichier est déplacé d'un enregistrement en avant puis un enregistrement est lu à rebours jusqu'à la fin du fichier.
Stride Read Lecture d'un fichier par saut de bande. Cette opération n'a de sens qu'avec un tableau de disques RAID. La valeur stridedéfinit le nombre de blocs lus ou écrits avant de passer au disque suivant. Cette valeur affecte principalement le placement des méta-données du système de fichiers. En effet, il ne faudrait pas que ces méta-données soient placées sur un seul disque du tableau ; ce qui serait très pénalisant en termes de performances.
Fread, Lecture avec fread() Lecture d'un fichier à l'aide de la fonctionfread()de la bibliothèque standard. La lecture se fait enregistrement par enregistrement vers une mémoire tampon dans l'espace utilisateur jusqu'à la fin du fichier.
Freread, Relecture avec fread() Relecture d'un fichier récemment lu à l'aide de la fonctionfread()la bibliothèque standard. Le but de cette de opération est identique à celui de larelecture définie ci-dessus. Comme dans le cas précédent, les données relues sont stockées dans l'espace utilisateur.
Les définitions des opérations évaluées en écriture sont les suivantes :
Write, Écriture Écriture d'un nouveau fichier enregistrement par enregistrement jusqu'à ce que la taille définie soit atteinte.
Re-write, Ré-écriture Réécriture d'un fichier existant. Comme dans le cas de la relecture, les performances doivent être meilleures que lors de l'écriture initiale sachant que les méta-données du fichier manipulé sont déjà en place. Cette opération ouvre le fichier existant, positionne le pointeur de fichier au début et réécrit enregistrement par enregistrement la totalité du fichier. La fermeture du fichier met à jour les méta-données.
5 http://www.linux-mag.com/ 6 http://www.linux-mag.com/id/7497/1/ 7 https://computing.llnl.gov/?set=code&page=sio_downloads 8 http://www.iozone.org/
3
Comment évaluer les performances des fonctions de stockage d'un système ?
Random Write, Écriture aléatoire Écriture d'un fichier unique avec des accès aléatoires enregistrement par enregistrement dans le fichier. Les écritures s'arrêtent dès que le nombre d'enregistrements écrit atteint la taille du fichier. Le but de cette opération est identique à la lecture aléatoire.
Record Rewrite, Réécriture par enregistrements Écriture ou réécriture en un point particulier d'un fichier. Cette opération est intéressante car elle permet de mettre en évidence les fonctionnalités d'un système de fichiers (et|ou) d'un noyau. Les performances doivent être améliorées si l'enregistrement est dimensionné pour loger dans les divers caches : CPU, TLB, noyau, système de fichiers, etc.
Fwrite, Lecture avec fwrite() Écriture d'un fichier à l'aide de la fonctionfwrite()de la bibliothèque standard. Exactement comme dans le cas de la lecture avecfread(), l'écriture se fait enregistrement par enregistrement depuis une mémoire tampon dans l'espace utilisateur jusqu'à la fin du fichier.
Frewrite, Réécriture avec fwrite() Réécriture d'un fichier récemment écrit à l'aide de la fonctionfwrite()de la bibliothèque standard. Le but de cette opération est identique à celui de laréécrituredéfinie ci-dessus. Comme dans le cas précédent, les données relues sont stockées dans l'espace utilisateur.
4. Les échantillons
Pour les besoins de ce billet, voici quelques échantillons des résultats obtenus avec mon transportable Dell M6300 dont les caractéristiques sont données ci-après. À titre d'élément de comparaison, les mêmes évaluations ont été lancées sur une instance de machine virtuelle KVM hébergée sur la même plateforme matérielle. La solution utilisée pour la virtualisation 9 est décrite dans l'articleVirtualisation système et enseignement.
Bien entendu, les résultats présentés ici n'ont aucune valeur sachant que la seule motivation ici est l'illustration des résultats produits par les outils. Ce ne sont que des exemples.
4.1. Configuration du système hôte
Configuration matérielle
• Processor: Intel Core 2 Duo CPU T7500 @ 2.20GHz (Total Cores: 2),
• Motherboard: Dell 0JM680, Chipset: Intel Mobile PM965/GM965/GL960 + ICH8M-E,
• System Memory: 3964MB,
• Disk: 160GB ST9160823ASG,
• Graphics: Quadro FX 1600M 512MB (625/800MHz),
• Monitor: Option "TwinViewXineramaInfoOrder" "DFP-0"(--) Apr 15 13:28:32 NVIDIA(0): Seiko
Configuration logicielle
• OS: Debian unstable/sid,
• Kernel: 2.6.33.2 (x86_64),
• Desktop: KDE,
• Display Server: X.Org Server 1.7.6,
• Display Driver: nvidia 195.36.07.03, OpenGL: 3.3.0,
• Compiler: GCC 4.4.3,
• File-System: ext4,
• Screen Resolution: 1920x1200
Configuration stockage Le disque dur du transportable a la référence ST9160823ASG. C'est un disque de 160GB avec un cache de 8MB et une vitesse de rotation de 7200rpm. Il existe plusieurs solutions pour obtenir les paramètres de configuration d'un disque. On peut notamment utiliser l'option-ides commandeshdparmetsmartctl. # smartctl -i /dev/sda smartctl 5.40 2010-03-16 r3077 [x86_64-unknown-linux-gnu] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF INFORMATION SECTION === Model Family: Seagate Momentus 7200.2 series Device Model: ST9160823ASG Serial Number: 5NK0XVRY Firmware Version: 3.ADD User Capacity: 160 041 885 696 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Mon Apr 19 09:16:38 2010 CEST
9 http://www.linux-france.org/prj/inetdoc/articles/vm/
4
Comment évaluer les performances des fonctions de stockage d'un système ?
SMART support is: Available - device has SMART capability. SMART support is: Enabled
Les fonctions de gestion de volume logique (LVM) ont été utilisées pour le partitionnement de l'unique disque dur. # pvdisplay | grep PV | grep -v UUID  PV Name /dev/sda2  PV Size 148,81 GiB / not usable 2,17 MiB
Les volumes logiques sont formatés avec le systèmeext4. $ mount | grep ^/dev /dev/mapper/Amethyste-root on / type ext4 (rw,errors=remount-ro) /dev/sda1 on /boot type ext3 (rw) /dev/mapper/Amethyste-home on /home type ext4 (rw) /dev/mapper/Amethyste-tmp on /tmp type ext4 (rw) /dev/mapper/Amethyste-usr on /usr type ext4 (rw) /dev/mapper/Amethyste-var on /var type ext4 (rw)
Les propriétés du système de fichiers dans lequel les tests sont effectués sont obtenues avec la commandetune2fs.
# tune2fs -l /dev/mapper/Amethyste-home tune2fs 1.41.11 (14-Mar-2010) Filesystem volume name: <none> Last mounted on: /home Filesystem UUID: 712216bc-cba2-4696-b746-a7cdefe76269 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index \  filetype needs_recovery extent sparse_super large_file uninit_bg Filesystem flags: signed_directory_hash Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 3932160 Block count: 15728640 Reserved block count: 786432 Free blocks: 6004161 Free inodes: 3784500 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 1020 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Filesystem created: Tue Jun 24 10:11:14 2008 Last mount time: Fri Apr 16 08:35:46 2010 Last write time: Fri Apr 16 08:35:46 2010 Mount count: 16 Maximum mount count: 20 Last checked: Mon Apr 5 20:44:26 2010 Check interval: 15552000 (6 months) Next check after: Sat Oct 2 20:44:26 2010 Lifetime writes: 377 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Journal inode: 8 Default directory hash: tea Directory Hash Seed: e8c9bd20-a3ca-4b34-91e6-3e12401ad5be Journal backup: inode blocks
4.2. Configuration du système virtuel
Configuration matérielle
• Processor: QEMU Virtual CPU 0.12.3 @ 2.19GHz (Total Cores: 1),
• Motherboard: Unknown,
• Chipset: Intel 440FX - 82441FX PMC + SB,
• System Memory: 1003MB,
• Disk: 40GB,
• Graphics: Cirrus Logic GD 5446
Configuration logicielle
• OS: Debian testing,
• Kernel: 2.6.32-3-amd64 (x86_64),
• Compiler: GCC 4.4.3,
5
• File-System: ext3/ext4,
• Screen Resolution: Unknown
Comment évaluer les performances des fonctions de stockage d'un système ?
Configuration stockage Les tests sont effectués sur un disque virtuel ajouté à la machine virtuelle de base. Voici la liste des manipulations effectuées.
• Sur le système hôte : $ mkdir ~/vm/bench $ cd ~/vm/bench $ ../scripts/diff-img.sh vm0-debian-testing-amd64-base.qcow2 vm-bench.qcow2 $ kvm-img create -f qcow2 target-disk.qcow2 40G $ ../scripts/startup.sh vm-bench.qcow2 1024 2 \  -drive file=target-disk.qcow2,if=virtio,boot=off
10 Les sources des scripts utilisés sont donnés dans la sectionConfiguration système de l'articleVirtualisation système et enseignement.
• Sur le système virtuel : # fdisk -l /dev/vdb
Disk /dev/vdb: 42.9 GB, 42949672960 bytes 16 heads, 63 sectors/track, 83220 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Disk identifier: 0x00000000
 Device Boot Start End Blocks Id System /dev/vdb1 1 83220 41942848+ 83 Linux
# mkfs.ext4 /dev/vdb1 # mount /dev/vdb1 /mnt # adduser --home /mnt/bench bench Warning: The home dir /mnt/bench you specified already exists. Adding user `bench' ... Adding new group `bench' (1001) ... Adding new user `bench' (1001) with group `bench' ... The home directory `/mnt/bench' already exists. Not copying from `/etc/skel'. Entrez le nouveau mot de passe UNIX : Retapez le nouveau mot de passe UNIX : passwd : le mot de passe a été mis à jour avec succès Changing the user information for bench Enter the new value, or press ENTER for the default  Full Name []: Ben Che  Room Number []:  Work Phone []:  Home Phone []:  Other []: Is the information correct? [Y/n] # su bench $ cd $ time phoronix-test-suite benchmark phil-24236-10417-13128
Sur ce disque dédié aux tests, les fonctions de gestion de volume logique ne sont pas utilisées.
$ mount | grep ^/dev /dev/mapper/vm--debian-root on / type ext3 (rw,errors=remount-ro) /dev/hda1 on /boot type ext2 (rw) /dev/mapper/vm--debian-home on /home type ext3 (rw) /dev/mapper/vm--debian-usr on /usr type ext3 (rw) /dev/mapper/vm--debian-var on /var type ext3 (rw) /dev/vdb1 on /mnt type ext4 (rw)
Comme sur le système hôte, les propriétés du système de fichiers dans lequel les tests sont effectués sont obtenues avec la commandetune2fs.
# tune2fs -l /dev/vdb1 tune2fs 1.41.11 (14-Mar-2010) Filesystem volume name: <none> Last mounted on: /mnt Filesystem UUID: db41ca8c-a339-4729-80cb-4e506d5538a9 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index \  filetype needs_recovery extent flex_bg sparse_super \  large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 2621440 Block count: 10485712 Reserved block count: 524285 Free blocks: 10276158 Free inodes: 2621429
10 http://www.linux-france.org/prj/inetdoc/articles/vm/vm.network.vde_switch.html#vm.network.vde_switch.system
6
Comment évaluer les performances des fonctions de stockage d'un système ?
First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 1021 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Flex block group size: 16 Filesystem created: Mon Apr 19 15:35:58 2010 Last mount time: Mon Apr 19 15:40:01 2010 Last write time: Mon Apr 19 15:40:01 2010 Mount count: 1 Maximum mount count: 26 Last checked: Mon Apr 19 15:35:58 2010 Check interval: 15552000 (6 months) Next check after: Sat Oct 16 15:35:58 2010 Lifetime writes: 773 MB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: e49dd145-0ac0-4a5e-aac9-2758454921f6 Journal backup: inode blocks
4.3. Les macro-benchmarks phoronix
J'ai testé trois suites proposées avec le paquet phoronix-test-suite sur le transportable M6300 :disk,computationalet linux-system. Dans les trois cas, on obtient un temps d'exécution des tests totalement incompatible avec la durée d'une séance de travaux pratiques. C'est d'autant plus frustrant, que les critères qui qualifient un banc d'essai de qualité sont vérifiés. Les opérations mesurées sont très variées et se rapprochent ainsi d'un scénario réel d'utilisation du système et les temps d'exécution sont suffisamment longs pour passer outre l'utilisation des caches et des optimisations liées une fonction du noyau.
Dans les trois tableaux ci-dessous, on trouve dans la colonne de gauche le temps d'exécution d'une suite sur le système hôte et dans la colonne de droite le temps d'exécution de la même suite sur une instance de système virtuel. La dernière ligne de chaque tableau donne les liens vers l'affichage des résultats.
Tableau 1. Suite disk
Système hôte
$ time phoronix-test-suite benchmark disk <snipped/> real 292m23.586s user 7m54.765s sys 20m31.907s
Système virtuel
$ time phoronix-test-suite benchmark phil-24236-10417-13128 <snipped/> real 453m30.958s user 11m2.421s sys 20m43.946s
11 Les résultats sont disponibles à l'adresseDebian-unstable-m6300ou sous forme de fichier PDF :debian-unstable-12 m6300-kvm-disk.pdf
Tableau 2. Suite computational
Système hôte
$ time phoronix-test-suite benchmark computational <snipped/> real 212m7.386s user 77m32.570s sys 2m27.696s
Système virtuel
$ time phoronix-test-suite benchmark phil-24027-7738-19351 <snipped/> real 75m35.505s user 62m16.750s sys 2m4.836s
13 Les résultats sont disponibles à l'adressedebian-unstable-m6300-computationalou sous forme de fichier PDF : 14 debian-unstable-m6300-kvm-computational.pdf
Tableau 3. Suite linux-system
Système hôte
$ time phoronix-test-suite benchmark linux-system <snipped/> real 333m5.239s user 186m17.410s sys 11m32.569s
Système virtuel
$ time phoronix-test-suite benchmark phil-18060-16906-20793 <snipped/> real 75m35.505s user 62m16.750s sys 2m4.836s
15 Les résultats sont disponibles à l'adressedebian-unstable-m6300-linux-systemou sous forme de fichier PDF :debian-16 unstable-m6300-kvm-linux-system.pdf
11 http://global.phoronix-test-suite.com/index.php?k=profile&u=bench-2712-11189-19311 12 http://www.linux-france.org/~platu/weblog/telechargement/debian-unstable-m6300-kvm-disk.pdf 13 http://global.phoronix-test-suite.com/index.php?k=profile&u=bench-6885-4149-6121 14 http://www.linux-france.org/~platu/weblog/telechargement/debian-unstable-m6300-kvm-computational.pdf 15 http://global.phoronix-test-suite.com/index.php?k=profile&u=bench-19298-27542-10343 16 http://www.linux-france.org/~platu/weblog/telechargement/debian-unstable-m6300-kvm-linux-system.pdf
7
17 http://www.linux-mag.com/ 18 http://www.linux-mag.com/id/7642/
Les résultats présentés ci-dessous ne sont que des échantillons. Ils ne constituent pas un véritable banc d'éssai sachant que les commandes n'ont été exécutées qu'une seule fois. Pour bien faire, il aurait fallu faire la moyenne d'au moins 5 mesures de chacune des valeurs affichées dans les deux tableaux.
Avertissement
215
227
1459
1137
3393
924
474
1046
13
153
284
543
150
5592384
15379056
Moyenne
Écart type
6094159
Arborescence «assez profonde» Dans ce mode d'évaluation, on lance la création puis l'effacement de 4 répertoires de «premier rang» ayant chacun 8 niveaux de sous-répertoires. L'arborescence ainsi définie est évaluée avec 4 dimensions de fichiers différentes dans chacun des sous-répertoires.
8
Tableau 4. Arborescence peu profonde
• 2 fichiers dont la taille correspond à 1024 blocs, soit 4MB $ for size in "1 16" "128 8" "256 4" "1024 2" do set -- $size ~/bin/fdtree.bash -d 8 -l 4 -f $2 -s $1 >output_fdtree_deep_$1.txt done
Répertoires effacés /s
• 16 fichiers dont la taille correspond à 1 bloc, soit 4KB
• 8 fichiers dont la taille correspond à 128 blocs, soit 512KB
Fichiers par niveau
• 4 fichiers dont la taille correspond à 256 blocs, soit 1MB
Volume KiB
20114
21873
618
10684
Volume KiB/s
Fichiers créés / s
Répertoires créés /s
Arborescence «peu profonde» Dans ce mode d'évaluation, on lance la création puis l'effacement de 8 répertoires de «premier rang» ayant chacun 4 niveaux de sous-répertoires. L'arborescence ainsi définie est évaluée avec 4 dimensions de fichiers différentes dans chacun des sous-répertoires.
Les résultats des suites de tests exécutées illustrent parfaitement la problématique desMacro-Benchmarks. D'un côté ces résultats sont très intéressants parce qu'ils reflètent la complexité du paramétrage d'un système d'exploitation en montrant que les outils donnent des mesures assez contrastées. D'un autre côté, l'interprétation et l'analyse des résultats devient plus complexe sachant qu'une même configuration n'obtient pas toujours le meilleur score. Nous sommes ramenés au point de départ : quelle est la suite qui correspond le mieux au profil des utilisateurs du système évalué ?
17 Pour réaliser les tests suivants, je me suis appuyé sur l'article du siteLINUX Magazine intituléImproving MetaData 18 Performance of the Ext4 Journaling Device. Voici les résultats de plusieurs tests successifs, réalisés sur le transportable M6300 dont la configuration est donnée ci-dessus.
L'outil fdtree est utilisé suivant 2 modes pour évaluer les performances des opérations sur les méta-données du système de fichiers Ext4. Là encore, la configuration du transportable est un facteur limitant dans la conduite des tests. En effet, le volume total disponible sur la partition utilisée est inférieur à 22GB.
16
2137
• 2 fichiers dont la taille correspond à 32 blocs, soit 128KB
• 2 fichiers dont la taille correspond à 24 blocs, soit 96KB
Fichiers effacés /s
• 1 fichier dont la taille correspond à 48 blocs, soit 192KB $ for size in "1 16" "24 2" "32 2" "48 1" do set -- $size ~/bin/fdtree.bash -d 4 -l 8 -f $2 -s $1 >output_fdtree_short_$1.txt done
• 16 fichiers dont la taille correspond à 1 bloc, soit 4KB
2240
2184
1941
116
2
1
2
22369536
624
615
16777152
598
633
16777152
2184
27582
Comment évaluer les performances des fonctions de stockage d'un système ?
4.4. Le micro-benchmark fdtree
Cette dernière suite reprend des éléments des deux précédentes et peut être considérée comme un panachage entre mesure de performances système et stockage.
28826
2175
Volume KiB/s
3404
Record MB
1
Moyenne
4
4681
4681
1171
2340
2340
3511
4160
Fichiers effacés /s
19 Pour réaliser les tests suivants, je me suis appuyé sur l'article du siteLINUX Magazine intituléI Feel the Need for 20 Speed: Linux File System Throughput Performance, Part 1. Voici les résultats de trois tests successifs, réalisés sur le transportable M6300 dont la configuration est donnée ci-dessus.
1170
1127
1521
1101
Dans l'ordre des tests lancés ci-après, le fichier de 16GB sera constitué de 16000 enregistrements de 1MB, puis de 4000 enregistrements de 4MB, puis de 2000 enregistrements de 8MB et enfin de 1000 enregistrements de 16MB.
49177
49259
49358
4.5. Le micro-benchmark iozone
49111
49045
48974
real 77m1.963s user 0m16.416s sys 6m46.863s
49416
49257
49019
Read KB/s
Re-read KB/s
9
Fichiers par niveau
780
752
4
2
8
780
48
668
Volume KiB
Tableau 5. Arborescence assez profonde
2995
42400
Random Read KB/s
40922
78740
49303
49391
26883
43206
49334
36678
34756
45247
46650
45083
46472
19 http://www.linux-mag.com/ 20 http://www.linux-mag.com/id/7525/
Fichiers créés / s
Répertoires effacés /s
780
89
44
19
225
Répertoires créés /s
303
748
299584
19248272
Moyenne
19173376
38346752
Écart type
19173376
13451914
45220
45869
171
Bien que l'outil fdtree soit très intéressant, les valeurs des échantillons présentés dans ces deux tableaux sont un peu trop «dispersées» pour être significatives. En effet, même avec les chiffres du nombre de répertoires créés par seconde pour lesquels le volume de méta-données unitaire est constant, les écarts types sont très importants.
De même que dans la section précédente, les résultats présentés ci-dessous ne sont que des échantillons. Ils ne constituent pas un véritable banc d'essai sachant que les commandes n'ont été exécutées qu'une seule fois. Pour bien faire, il aurait fallu faire la moyenne d'au moins 5 mesures de chacune des valeurs affichées dans les deux tableaux.
real 87m0.101s user 0m11.215s sys 6m23.631s
$ time iozone -Rb spreadsheet_output_1M.wks -s 16G -r 1M > output_1M.txt ;\ time iozone -Rb spreadsheet_output_4M.wks -s 16G -r 4M > output_4M.txt ;\ time iozone -Rb spreadsheet_output_8M.wks -s 16G -r 8M > output_8M.txt ;\ time iozone -Rb spreadsheet_output_16M.wks -s 16G -r 16M > output_16M.txt
Tableau 6. Débits en lecture
real 75m35.788s user 0m15.659s sys 6m47.312s
real 74m59.931s user 0m13.853s sys 6m42.174s
Avertissement
5068
7285
Backward Read KB/s
28644
Stride Read KB/s
Fread KB/s
246
Bref, même si le temps d'une exécution de l'outil est compatible avec la durée d'une séance de travaux pratiques, il est tout de même nécessaire de disposer d'un temps important pour mener un banc d'essai qui puisse produire des résultats valides.
On retrouve ici les deux gros défauts de ces tests effectués à titre d'illustration. Tout d'abord, il aurait fallu répéter un dizaine de fois l'exécution d'un jeu de paramètres et calculer les valeurs moyennes des résultats obtenus. Ensuite, il aurait fallu disposer d'un espace libre suffisant pour pouvoir manipuler un nombre constant de fichiers par niveau.
16
Comment évaluer les performances des fonctions de stockage d'un système ?
Le but de ces tests est de caractériser les performances du système de fichiers ext4 en fonction de quatre tailles d'enregistrement 1MB, 4MB, 8MB et 16MB. La taille du fichier de test est fixée à 16GB, c'est à dire une valeur plus importante que celle des caches du processeur, du CPU et du système de fichiers. Le but est justement d'obtenir des mesures de performances indépendantes des optimisations de chacun des éléments du système.
6073
82
171
Re-fread KB/ s
Écart type
Écart type
397
50948
51129
50817
Moyenne
8
16
$Id: storage-bench.xml 1480 2010-04-23 13:23:15Z latu $
8
171
Re-write KB/s
Read KB/s
16
Record MB
4400
48954
49141
44399
47546
48318
5. La conclusion
Re-read KB/s
49257
50147
49170
49791
49423
49586
50578
49558
Re-fread KB/ s
49334
45083
246
51123
49946
50392
Voilà ! Si vous êtes parvenu jusqu'à ces lignes, je vous en remercie et je serais très honoré de partager vos remarques sur le sujet. Il y a manifestement beaucoup à creuser sur la question.
49259
10
La conclusion de ce billet est en demi-teinte. D'un côté, on dispose d'un premier niveau de méthodologie et de classification qui permet de conduire un banc d'essai de qualité correcte. Le simple fait de ne plus délivrer de conclusions péremptoires sur la base d'un seul outil de test est une victoire modeste, mais une victoire quand même. D'un autre côté, je reste sur ma faim sur le plan pédagogique. Il est quasiment impossible d'obtenir des résultats valides en trois heures de travaux pratiques. Une piste consisterait à préparer des scripts d'exécution en lots pendant une première séance, puis à collecter et exploiter les résultats lors d'une seconde séance le lendemain. La rotation entre plusieurs groupes rend la chose difficile.
4
21 Ce billet est disponible en version imprimable au format PDF :storage-bench.pdf.
49045
Moyenne
51053
Write KB/s
À partir des données des deux tableaux ci-dessus, on observe des écarts de performances importants entre la première taille d'enregistrement évaluée (1MB) et les autres. Avec une taille d'enregistrement supérieure ou égale à 4MB les performances sont uniformes et les écarts types assez faibles.
Si on fait abstraction de la première ligne de chaque tableau, on peut considérer que l'on a une image correcte des performances du système de fichiers ext4 sur le transportable M6300 indépendante des optimisations et des caches. En effet, les débits relevés sont suffisamment proches d'une opération à l'autre.
6073
1059762
49596
60
50635
49085
48914
50717
50576
Re-fwrite KB/s
Fread KB/s
50668
171
Fwrite KB/s
Écart type
50657
1
526
49330
49840
50042
Stride Read KB/s
395
49595
50634
891097
1032083
1610483
3149958
Random Write KB/s
1200128
5068
45247
49573
48265
Backward Read KB/s
Record Rewrite KB/s
Random Read KB/s
37177
Tableau 7. Débits en écriture
50139
Record MB
82
Comment évaluer les performances des fonctions de stockage d'un système ?
7285
44554
45607
40922
47038
21 http://www.linux-france.org/~platu/weblog/telechargement/storage-bench.pdf
Un pour Un
Permettre à tous d'accéder à la lecture
Pour chaque accès à la bibliothèque, YouScribe donne un accès à une personne dans le besoin