Le Linux Benchmarking Toolkit (LBT)
3. Le Linux Benchmarking Toolkit (LBT)
Contenu de cette section
Je propose ici un ensemble d'outils pour l'évaluation de performances sous
Linux. C'est la version préliminaire d'un vaste environnement d'évaluation
de performances pour Linux, il est destiné à être amélioré et à
voir ses fonctionnalités étendues. Prenez le pour ce qu'il vaut,
c'est-à-dire une proposition. Si vous pensez que cette suite de test n'est pas
valable, prenez la liberté de m'envoyer (ndt : à l'auteur et non au
traducteur, merci :-) vos critiques par e-mail et soyez sûrs que je serai
heureux d'intégrer les changements que vous aurez suggéré dans la mesure
du possible. Avant d'entamer une polémique, lisez ce HOWTO et les documents
cités en référence : les critiques informés sont les bienvenus, les
critiques stériles ne le sont pas.
3.1 Motivations
Elles sont dictées par le bon sens, tout simplement :
- Cette suite ne doit pas nécessiter plus d'une journée de durée
d'exécution. En matière de benchmarks comparatifs (diverses
exécutions), personne ne veut passer des jours à essayer de trouver
la configuration matérielle le plus rapide pour un système donné. Idéalement,
l'ensemble de la suite devrait pouvoir tourner en 15 minutes sur une
machine moyenne.
- Tout le code source doit être disponible librement sur le Net, pour
des raisons évidentes.
- Les benchmarks devraient fournir des chiffres simples et reflétant la
performance mesurée.
- Il devait y avoir un mélange de benchmarks synthétiques et de
benchmarks applicatifs.
- Chacun des benchmarks synthétiques devrait pousser un
sous-système particulier à ses limites.
- Les résultats des benchmarks synthétiques ne devraient
pas être combinés par le biais d'une moyenne afin d'en extraire un
facteur de mérite global (cela va à l'encontre du principe fondateur des
benchmarks synthétiques et conduit à une perte d'information considérable).
- Les benchmarks applicatifs devraient être représentatifs de tâches
couramment exécutées sur des systèmes Linux.
3.2 Sélection des benchmarks
J'ai sélectionné 5 suites des benchmarks différentes en évitant autant
que possible les recouvrements dans les tests :
- Compilation du noyau 2.0.0 (configuration par défaut) avec gcc.
- Whetstone version 10/03/97 (la version la plus récente de Roy Longbottom).
- xbench-0.2 (avec les paramètres d'exécution rapide).
- Les benchmarks UnixBench version 4.01 (résultats partiels).
- Les benchmarks de la suite BYTEmark du magazine BYTE beta release 2
(résultats partiels).
Pour les tests 4 et 5, "(résultats partiels)" signifie qu'une partie seulement
des résultats produits est prise en compte.
3.3 Durée des tests
- Compilation du noyau 2.0.0 : 5 - 30 minutes, selon la performance
réelle de votre machine.
- Whetstone : 100 secondes.
- Xbench-0.2 : < 1 heure.
- Les benchmarks d'UnixBench version 4.01 : environs 15 minutes.
- Les benchmarks de la suite BYTEmark du magazine BYTE : environs 10 minutes.
3.4 Commentaires
Compilation du noyau 2.0.0
- Quoi : c'est le seul benchmark applicatif de la LBT.
- Le code est largement disponible (càd que j'ai finalement trouvé une
utilisation pour mes vieux CD-ROMs Linux).
- La plupart des linuxiens recompilent leur noyau assez souvent, c'est donc
une mesure significative de la performance globale.
- Le noyau est gros et gcc utilise une bonne partie de la mémoire (ndt :
surtout à l'édition de liens) : ceci contribue à atténuer le biais
induit par le cache L2 lorsque l'on se contente de passer de petits tests.
- Les E/S vers le disque sont fréquentes.
- Procédure de test : trouvez une antique arborescence source de 2.0.0,
compilez la avec les options par défaut (make config, appuyez sur Enter
autant de fois que nécéssaire). Le temps affiché doit correspondre
à la durée passée sur la compilation càd après que vous ayez
tapé make zImage (sans prendre en compte le make dep clean). Notez
que l'architecture cible par défaut est i386, donc si vous compilez
sur une autre architecture, gcc devrait être en mesure de cross-compiler
en utilisant i386 en tant qu'architecture cible.
- Résultats : la durée de compilation en minutes et secondes (s'il vous
plait, ne rapportez pas les fractions de secondes).
La suite Whetstone
- Quoi : mesure la performance en calcul flottant pur à l'intérieur
d'une courte (et dense) boucle. Le code source (en C) est assez lisible
et il est très facile de voir quelles sont les opérations flottantes
impliquées.
- C'est le plus court des tests de la LBT :-).
- C'est un "Vieux Classique" : des chiffres sont disponibles pour comparaison,
ses défauts et ses faiblesses sont bien connues.
- Procédure de test : le code source le plus récent devrait être
téléchargé depuis le site d'Aburto. Compilez le et exécutez le en
mode double précision. Spécifiez gcc et -O2 en tant que pré-processeur
et option du compilateur respectivement. Définissez aussi la variable du
pré-processur POSIX à 1 pour préciser le type de machine.
- Résultats : un indice de performance en calcul flottant exprimé en MWIPS.
Xbench-0.2
- Quoi : mesure la performance de serveurs X.
- La mesure en xStones fournie par xbench est une moyenne pondérée de
quelques tests rapportés aux performances obtenues sur une vieille station
Sun ne disposant que d'un display d'un seul bit de profondeur (ndt : en
clair, c'est du monochrome pur et dur). Mouais... on peut légitimement
se demander si xbench est véritablement adéquat en tant que test
pour des serveurs X modernes. Néanmoins, c'est le meilleur outil que
j'ai trouvé.
- Procédure de test : compilez avec -O2. On spécifiera aussi quelques
options pour une exécution courte :
./xbench -timegoal 3 >
results/name_of_your_linux_box.out .
Pour générer l'indice xStones, il nous faudra encore lancer un script
awk; la façon la plus simple de le faire étant de taper
make summary.ms. Jetez un coup d'oeuil au fichier summary.ms : l'indice
xStone de votre système est dans la dernière colonne de la ligne
contenant le nom de votre machine -- nom que vous aurez spécifié
pendant le test.
- Résultats : un indice de performances exprimé en xStones.
- Note : ce test, en l'état, est dépassé. Il devrait être ré-écrit.
UnixBench version 4.01
- Quoi : mesure la performance globale d'un système UNIX. Ce test met en
oeuvre évidence la performance des E/S fichier et de la gestion du
multi-tâches par le noyau.
- J'ai supprimé tous les résultats de tests arithmétiques et je n'ai
conservé que les tests orientés système.
- Procédure de test : make avec -O2. Exécution avec
./Run -1
(tournez chacun des tests une fois). Vous trouverez les résultats dans le
fichier ./results/report.
Calculez la moyenne géométrique des indices de EXECL THROUGHPUT,
FILECOPY 1, 2, 3, PIPE THROUGHPUT, PIPE-BASED CONTEXT SWITCHING, PROCESS
CREATION, SHELL SCRIPTS et SYSTEM CALL OVERHEAD.
- Résultats : un indice de performance du système.
(ndt : la moyenne géométrique se définit comme la racine n-ième
du produit des n termes considérés)
Les benchmarks Bytemark du magazine BYTE
- Quoi : fournit une bonne mesure de la performance CPU. Voici un extrait
de la documentation : "Ces benchmarks ont étés conçu de façon
à mettre en évidence la limite supérieure de la CPU, de la FPU
et de l'architecture mémoire d'un système. Ils ne peuvent mesurer
la performance du sous-système graphique, des accès disque ou du
débit réseau (ce sont là le domaine d'un ensemble différent
de benchmarks). C'est pourquoi, il est souhaitable que vous n'utilisiez
les résultats de ces tests qu'en tant qu'élément d'appréciation
partielle, et non pas totale, lors de l'évaluation de la performance d'un
système."
- J'ai supprimé tous les résultats de test FPU puisque la suite Whetstone
est tout aussi représentative des performances à cet égard.
- J'ai décomposé les tests entiers en deux groupes : ceux qui sont plus
représentatifs de la performance cache mémoire/CPU, et ceux qui utilisent
l'arithmétique entière de la CPU.
- Procédure de test : make avec -O2. Exécutez le test avec ./nbench >myresults.dat ou quelque chose d'approchant. Puis, à partir de
myresults.dat, calculez la moyenne géométrique des indices des tests
STRING SORT, ASSIGNMENT et BITFIELD. Ceci vous donnera l'indice
mémoire. Calculez la moyenne géométrique des indices des tests NUMERIC
SORT, IDEA, HUFFMAN et FP EMULATION: c'est l'indice entier.
- Résultats : un indice mémoire et un indice entier calculés comme
expliqué ci-dessus.
3.5 Améliorations possibles
La suite de benchmarks idéale tournerait en quelques minutes, comprendrait
des benchmarks synthétiques testant chaque sous-système séparément
et des benchmarks applicatifs fournissant des résultats pour différentes
applications. Elle produirait aussi automatiquement un rapport complet et
éventuellement l'enverrait par e-mail à une base de données centrale
sur le Web.
La portabilité n'est pas vraiment notre souci premier dans cette affaire.
Pourtant, une telle suite devrait tourner au moins sur toutes les versions
(> 2.0.0) du noyau Linux, et ce dans toutes leurs déclinaisons possibles
(i386, Alpha, Sparc...).
Si quelqu'un a la moindre idée concernant l'évaluation de performances
réseau au moyen d'un test à la fois simple, facile d'emploi, fiable, et
dont la mise en oeuvre prendrait moins de 30 minutes (configuration et
exécution), s'il vous plait contactez-moi.
3.6 Formulaire de rapport LBT
Au-delà des tests, la procédure d'évaluation de performances n'aurait
pas été complète sans un formulaire décrivant la configuration matérielle
utilisée lors de leur exécution. Le voici donc : (il se conforme aux directives
prescrites dans la FAQ de comp.benchmarks) :
(ndt : le formulaire en question n'a délibérément pas été traduit,
de façon à ce que l'auteur de ce HOWTO puisse automatiser leur
traitement en vue de maintenir une base de données de résultats. Voir
la section 4 pour un exemple de formulaire correctement rempli).
3.7 Test de performances réseau
Le test des performances réseau est un véritable défi en soi puisqu'il
implique au moins deux machines: un serveur et une machine cliente. Pour cette
raison ce genre de test nécessite deux fois plus de temps pour être mis
en place, il y a plus de variables à contrôler, etc... Sur un réseau
Ethernet, il me semble votre meilleure option est le paquetage ttcp. (à
developper)
3.8 Les tests SMP
Les tests SMP sont un autre défi, et tout test conçu spécifiquement
pour un environnement SMP aura des difficultés à s'avérer valide dans
des conditions d'utilisation réelles parce que les algorithmes qui tirent
parti du SMP sont difficiles à développer. Il semble que les versions
du noyau Linux les plus récentes (> 2.1.30 ou pas loin) feront du scheduling
(ndt : ordonnancement de thread ou de processus) à grain fin ; je n'ai pas
plus d'information que ça pour le moment.
Selon David Niemi, "... shell8 de la suite Unixbench 4.01
fait du bon travail en matière de comparaison de matériel/SE similaires
en mode SMP et en mode UP."
(ndt : SMP = Symetric Multi-Processing, UP = Uni-Processor)
Chapitre suivant,
Chapitre Précédent
Table des matières de ce chapitre,
Table des matières générale
Début du document,
Début de ce chapitre
[22 février 2002, JDNet]
|