23-04-2010 15:26:01

Comment évaluer les performances des fonctions de stockage d'un système ?

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 !?

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 des benchmarks».

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.

Tout d'abord, j'ai commencé par réaliser une présentation baptisée Stockage 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.

La méthodologie

Après de nombreuses recherches, j'ai fini par trouver un article du site http://fsbench.filesystems.org/ intitulé Notes on a Nine Year Study of File System and Storage Benchmarking qui résume bien les limites de l'exercice. L'étude en question porte sur 415 benchmarks 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.

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 de benchmarks.

Les Macro-Benchmarks utilisent 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 tests Trace-based sont basés sur la répétition d'un trafic réel enregistré. Relativement à la catégorie précédente, 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.

Les Micro-Benchmarks se limitent à un ou deux types d'opérations. Ils sont utiles pour mesurer les caractéristiques 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 de Macro-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.

Le choix des outils

Comme indiqué ci-dessus dans la section consacrée au contexte, 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.

La suite Phoronix

La suite produite par le site Phoronix tend à devenir un standard de fait dans le monde du logiciel libre. Cette suite permet d'exécuter des outils appartenant aux catégories Macro-Benchmarks et Micro-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 test FS-Mark 3.3 sur le transportable M6300 se présentent de la façon suivante sur le site Phoronix 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 suite Phoronix est disponible sous forme de paquet (Debian|Ubuntu) à l'adresse http://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égorie Macro-Benchmarks, les suites disk, compilation, compression et computational ré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égorie Micro-Benchmarks est très étoffée et on y retrouve pratiquement tous les outils classiques.

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.

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 site LINUX Magazine. Il est intitulé Metadata Performance of Four Linux File Systems. L'outil de type Micro-Benchmark utilisé dans l'article est appelé fdtree est 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.

Les systèmes de fichiers avec iozone

Avec IOzone en entre vraiment dans la catégorie Micro-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 stride dé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 fonction fread() 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 fonction fread() de la bibliothèque standard. Le but de cette opération est identique à celui de la relecture 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.

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 fonction fwrite() de la bibliothèque standard. Exactement comme dans le cas de la lecture avec fread(), 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 fonction fwrite() de la bibliothèque standard. Le but de cette opération est identique à celui de la réécriture définie ci-dessus. Comme dans le cas précédent, les données relues sont stockées dans l'espace utilisateur.

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 est décrite dans l'article Virtualisation 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.

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 -i des commandes hdparm et smartctl.

# 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
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ème ext4.

$ 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 commande tune2fs.

# 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

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,

  • File-System: ext3/ext4,

  • Screen Resolution: Unknown

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
    

    Les sources des scripts utilisés sont donnés dans la section Configuration système de l'article Virtualisation 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 commande tune2fs.

    # 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
    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
    

Les macro-benchmarks phoronix

J'ai testé trois suites proposées avec le paquet phoronix-test-suite sur le transportable M6300 : disk, computational et 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 Système virtuel
$ time phoronix-test-suite benchmark disk
<snipped/>
real    292m23.586s
user    7m54.765s
sys     20m31.907s
$ time phoronix-test-suite benchmark phil-24236-10417-13128
<snipped/>
real    453m30.958s
user    11m2.421s
sys     20m43.946s
Les résultats sont disponibles à l'adresse Debian-unstable-m6300 ou sous forme de fichier PDF : debian-unstable-m6300-kvm-disk.pdf

Tableau 2. Suite computational

Système hôte Système virtuel
$ time phoronix-test-suite benchmark computational
<snipped/>
real    212m7.386s
user    77m32.570s
sys     2m27.696s
$ time phoronix-test-suite benchmark phil-24027-7738-19351
<snipped/>
real    75m35.505s
user    62m16.750s
sys     2m4.836s
Les résultats sont disponibles à l'adresse debian-unstable-m6300-computational ou sous forme de fichier PDF : debian-unstable-m6300-kvm-computational.pdf

Tableau 3. Suite linux-system

Système hôte Système virtuel
$ time phoronix-test-suite benchmark linux-system
<snipped/>
real    333m5.239s
user    186m17.410s
sys     11m32.569s
$ time phoronix-test-suite benchmark phil-18060-16906-20793
<snipped/>
real    75m35.505s
user    62m16.750s
sys     2m4.836s
Les résultats sont disponibles à l'adresse debian-unstable-m6300-linux-system ou sous forme de fichier PDF : debian-unstable-m6300-kvm-linux-system.pdf

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.

Les résultats des suites de tests exécutées illustrent parfaitement la problématique des Macro-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é ?

Le micro-benchmark fdtree

Pour réaliser les tests suivants, je me suis appuyé sur l'article du site LINUX Magazine intitulé Improving MetaData 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.

[Avertissement] Avertissement

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.

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.

  • 16 fichiers dont la taille correspond à 1 bloc, soit 4KB

  • 2 fichiers dont la taille correspond à 24 blocs, soit 96KB

  • 2 fichiers dont la taille correspond à 32 blocs, soit 128KB

  • 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
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.

  • 16 fichiers dont la taille correspond à 1 bloc, soit 4KB

  • 8 fichiers dont la taille correspond à 128 blocs, soit 512KB

  • 4 fichiers dont la taille correspond à 256 blocs, soit 1MB

  • 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

Tableau 4. Arborescence peu profonde

Fichiers par niveau Volume KiB Répertoires créés /s Fichiers créés /s Volume KiB/s Fichiers effacés /s Répertoires effacés /s
Moyenne 15379056 618 284 20114 1459 2137
Écart type 6094159 13 153 10684 1137 116
16 5592384 598 543 2175 3393 1941
2 16777152 615 227 21873 924 2184
2 22369536 624 215 27582 1046 2184
1 16777152 633 150 28826 474 2240

Tableau 5. Arborescence assez profonde

Fichiers par niveau Volume KiB Répertoires créés /s Fichiers créés /s Volume KiB/s Fichiers effacés /s Répertoires effacés /s
Moyenne 19248272 752 225 43206 1521 3511
Écart type 13451914 48 303 26883 1127 1171
16 299584 780 748 2995 4160 4681
8 19173376 780 89 45869 3404 4681
4 19173376 668 44 45220 1101 2340
2 38346752 780 19 78740 1170 2340

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.

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.

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.

Le micro-benchmark iozone

Pour réaliser les tests suivants, je me suis appuyé sur l'article du site LINUX Magazine intitulé I Feel the Need for 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.

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.

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.

[Avertissement] Avertissement

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.

$ 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

real    87m0.101s
user    0m11.215s
sys     6m23.631s

real    77m1.963s
user    0m16.416s
sys     6m46.863s

real    75m35.788s
user    0m15.659s
sys     6m47.312s

real    74m59.931s
user    0m13.853s
sys     6m42.174s

Tableau 6. Débits en lecture

Record MB Read KB/s Re-read KB/s Random Read KB/s Backward Read KB/s Stride Read KB/s Fread KB/s Re-fread KB/s
Moyenne 49045 49257 40922 45247 45083 49259 49334
Écart type 82 171 7285 5068 6073 246 171
1 48974 49019 28644 36678 34756 49358 49303
4 49111 49416 42400 46472 46650 49177 49391
8 49141 49423 45607 48265 49330 49586 49558
16 48954 49170 47038 49573 49596 48914 49085

Tableau 7. Débits en écriture

Record MB Write KB/s Re-write KB/s Random Write KB/s Record Rewrite KB/s Fwrite KB/s Re-fwrite KB/s
Moyenne 50817 50042 44399 1610483 50392 50635
Écart type 397 395 4400 891097 526 60
1 50139 49791 37177 3149958 51123 50668
4 51053 50147 44554 1200128 50657 50576
8 50948 49595 47546 1059762 49946 50578
16 51129 50634 48318 1032083 49840 50717

À 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.

La conclusion

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.

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.

Ce billet est disponible en version imprimable au format PDF : storage-bench.pdf.

$Id: storage-bench.xml 1480 2010-04-23 13:23:15Z latu $