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

Sujets

• Résultats électoraux de l'extrême gauche en France
• Enregistrement sonore
• Tableau d'honneur
• Inode
• Ext4
• Bloc de béton

Informations

• Publié par: Zawyag
• Nombre de lectures: 74
• Langue: Français

Extrait

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