Olivier Wenger

Benchmark ou comment tester un serveur

Il m’arrive régulièrement de devoir tester un serveur pour connaitre ses capacités, évaluer l’utilisation possible, etc… il existe plusieurs méthodes. Je vais en décrire quelques-unes simple à mettre en place.

Je traite ici d’un serveur sous Debian.

Voici quelques critères :

• Mesurer les performances CPU
• Tester la mémoire ram
• Débit et latence au disque dur
• Tester la connexion réseau (débit et latence)
• Stabilité du système (test sur plusieurs heures ou jours)

Monitoring

La première étape est de pouvoir superviser les tests et avoir un aperçu aussi bien en temps réel que dans le temps. Pour cela il y a plusieurs outils de monitoring :

En console

top : Le classique top est toujours pratique pour superviser l’état général du serveur en temps réel et contrôler que les tests en cours.

top - 17:47:54 up  2:15,  3 users,  load average: 0.18, 0.17, 0.09
Tasks: 194 total,   2 running, 192 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.1%us,  2.0%sy,  0.2%ni, 95.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   3095720k total,  1045784k used,  2049936k free,    62580k buffers
Swap:   907632k total,        0k used,   907632k free,   440860k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1413 root      20   0  202m  64m  13m S    3  2.1   7:35.45 Xorg

----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
  1   0  86  13   0   0| 148k  346k|   0     0 | 326B  706B|  25    42
  2   0   0  98   0   0|1867k   27k| 108B  232B|  12k    0 |  56    66
  2   0   0  97   0   0| 630k   46k|   0     0 |   0     0 |  42    47
  2   0   0  98   0   0|1074k   43k|   0     0 |   0     0 |  46    50

slurm : Un petit outil pour surveiller les interfaces réseaux.

      Active Interface: eth0                    Interface Speed: unknown

      Current RX Speed: 20464.52 KB/s          Current TX Speed: 448.83 KB/s
    Graph Top RX Speed: 20464.52 KB/s        Graph Top TX Speed: 648.21 KB/s
  Overall Top RX Speed: 20464.52 KB/s      Overall Top TX Speed: 648.21 KB/s
      Received Packets: 495542060           Transmitted Packets: 723671597
       GBytes Received: 139.571 GB           GBytes Transmitted: 821.331 GB
   Errors on Receiving: 0                Errors on Transmission: 0

Graphiques via HTTP :

Pour superviser les tests au fil du temps il est utile sinon indispensable d’avoir recours aux graphiques dans le style RDDTools. Il y a évidemment le classique mrtg mais j’ai une préférence pour munin qui est beaucoup plus puissant, précis sans être beaucoup plus lourd.

Graphique mémoire de Munin

Connexion réseau

Il importe ici de connaitre la connectivité du serveur à internet ainsi que la qualité du réseau (temps de latence, paquet perdu,.. ).

Débit

Pour connaitre le débit de la connexion internet en download vous pouvez télécharger un gros fichier :

wget http://test-debit.free.fr/image.iso
--2010-01-24 17:56:02--  http://test-debit.free.fr/image.iso
Résolution de test-debit.free.fr... 212.27.60.49
Connexion vers test-debit.free.fr|212.27.60.49|:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 678526976 (647M) [application/x-iso9660-image]
Saving to: `image.iso'

100%[======================================>] 678 526 976 11,2M/s   in 58s     

2010-01-24 17:57:00 (11,1 MB/s) - « image.iso » sauvegardé [678526976/678526976]

N’oubliez pas de supprimer l’image téléchargée afin de ne pas trop encombrer votre espace disque. Ensuite il ne faut pas oublier que ce test de débit est fait principalement pour tester les connexions ADSL > 20 mbps, hors il n’est pas rare de disposer d’une connexion de 100 mbps voir 1 gbps. Il faudra donc trouver quelque chose de plus costaud et effectuer plusieurs tests en parallèle.

En upload il suffit de récupérer ce fichier en ftp depuis un autre serveur par exemple.

Latence et réseau

Pour connaitre la qualité du réseau, les outils classiques comme ping ou encore traceroute sont là.

Performances des disques durs

Vous pouvez vérifier le débit avec hdparm :

hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads:   9790 MB in  2.00 seconds = 4900.65 MB/sec
 Timing buffered disk reads:  702 MB in  3.01 seconds = 233.54 MB/sec

Tester le cpu

Vous pouvez faire des tests de courtes durées comme chronométrer un décompression ou de longue durée (calculs). Voici quelques exemples :

Super PI

C’est une méthode qui va permettre de mesurer les performances du cpu sur une durée plus ou moins longue. C’est une application qui calcule les décimales du nombre Pi. Cette application est en 32 bits donc elle ne mettra pas à profit un cpu 64 bits (si vous le faite tourner sur une distribution 64 bits il faut installer ia32-libs ).

wget ftp://pi.super-computing.org/Linux/super_pi.tar.gz
tar xzf super_pi.tar.gz
./super_pi 20
------ Started super_pi run : Fri Jan 22 18:12:00 CET 2010
 ------ Ended super_pi run : Fri Jan 22 18:20:53 CET 2010
 Version 2.0 of the super_pi for Linux OS
 Fortran source program was translated into C program with version 19981204 of
 f2c, then generated C source program was optimized manually.
 pgcc 3.2-3 with compile option of "-fast -tp px -Mbuiltin -Minline=size:1000 -Mnoframe -Mnobounds -Mcache_align -Mdalign -Mnoreentrant" was used for the
 compilation.
 Start of PI calculation up to 16777216 decimal digits
 End of initialization. Time=       6.704 Sec.
 I= 1 L=       0        Time=      19.333 Sec.
 I= 2 L=       0        Time=      22.057 Sec.
 I= 3 L=       1        Time=      21.969 Sec.
 I= 4 L=       2        Time=      21.889 Sec.
 I= 5 L=       5        Time=      21.961 Sec.
 I= 6 L=      10        Time=      22.017 Sec.
 I= 7 L=      21        Time=      21.917 Sec.
 I= 8 L=      43        Time=      23.137 Sec.
 I= 9 L=      87        Time=      22.309 Sec.
 I=10 L=     174        Time=      21.897 Sec.
 I=11 L=     349        Time=      21.957 Sec.
 I=12 L=     698        Time=      23.033 Sec.
 I=13 L=    1396        Time=      22.265 Sec.
 I=14 L=    2794        Time=      22.045 Sec.
 I=15 L=    5588        Time=      21.957 Sec.
 I=16 L=   11176        Time=      22.109 Sec.
 I=17 L=   22353        Time=      22.225 Sec.
 I=18 L=   44707        Time=      22.349 Sec.
 I=19 L=   89415        Time=      21.913 Sec.
 I=20 L=  178831        Time=      22.061 Sec.
 I=21 L=  357662        Time=      22.745 Sec.
 I=22 L=  715326        Time=      21.429 Sec.
 I=23 L= 1430652        Time=      19.389 Sec.
 End of main loop
 End of calculation.    Time=     525.037 Sec.
 End of data output.    Time=       1.680 Sec.
 Total calculation(I/O) time=     526.717(     108.831) Sec.

Selon le nombre de décimales calculées (et surtout selon le cpu) le test durera de quelques minutes à quelques heures.

Temps de compression/décompression

cd /dev/shm;
wget ftp://ftp.ovh.net/made-in-ovh/bzImage/linux-2.6.31.5-ovh.tar.gz -O linux-2.6.31.5-ovh.tar.gz;
time gzip -d linux-2.6.31.5-ovh.tar.gz -c > /dev/null;
for i in ` seq 1 4` ; do time gzip -d linux-2.6.31.5-ovh.tar.gz -c > /dev/null & done

MySQL

mysql> SELECT benchmark(100000000,1+2);

Sinon vous pouvez essayer de manipuler de grandes quantités de données en regardant les temps d’exécution des requêtes.

Mettre la ram à vif

Un utilitaire pratique pour tester les performances des différentes mémoires du serveur (L1, L2, RAM, ..) est bandwidth :

wget http://home.comcast.net/~fbui/bandwidth.tar.gz
tar xzf bandwidth.tar.gz && chmod +x bandwidth bandwidth64
./bandwidth
L1 cache sequential read 8022.07 MB/sec
L1 cache sequential write 7524.32 MB/sec
L2 cache sequential read 6862.73 MB/sec
L2 cache sequential write 6318.39 MB/sec
Main memory sequential read 2207.22 MB/sec
Main memory sequential write 1602.92 MB/sec

Conclusion

Évidemment cela ne sert à rien de bourriner sur tout ce qui passe sous la main, ces tests sont à adapter à l’utilisation envisagée. Cela vaut la peine de pousser un peu pour bien se rendre compte des limites et ainsi avoir en tête le contexte et l’évolution de son utilisation à moyen terme.

Si on en a la possibilité, installer l’application voulue et la tester, ce sera le test le plus adapté. Le test le plus important sera celui du point faible du serveur ou de l’infrastructure, par exemple si le serveur est situé géographiquement loin ou encore si les données sont sur un SAN accessible en iSCSI, etc…

Si vous avez d’autres habitudes, propositions vous pouvez les indiquer en commentaire, je complèterai l’article en conséquence.

Péripéties de la vie quotienne (ou pas…)

Ce billet change légèrement de la ligne éditoriale habituelle, Il décrit une journée qui était censée être habituelle hormis un simple détail : migration vers Gutsy, la nouvelle version d’Ubuntu.

Ce matin (j’avais spécialement attendu ce matin pour espérer échapper aux bouchons sur l’autoroute des serveurs Canonical en circulant aux heures creuses par rapport au fuseau horaire américain et en ayant attendu 36 heures après la sortie). Jusque là j’avais raison, la mise à jour se télécharge normalement. Ensuite installation et tout le blabla jusqu’au moment où tout plante après près de 2 heures de compilation.

Là je me dis : « Bon, qu’est-ce qu’on parie que le serveur X on ne le reverra pas de sitôt »… et j’avais raison. Je redémarre, arrivée en mode console. Je finis l’update/upgrade dedans (d’ailleurs la prochaine fois, promis je fais la maj en console sans rien qui tourne à côté…). Quelques messages d’erreurs et retouches plus tard, je redémarre. Bon toujours pas de X, on bidouille un peu le xorg.conf pour avoir au moins un écran et là ça se lance. Enfin Gutsy. Je me rappelle qu’une nouveauté c’est l’édition simple via le menu pour gérer plusieurs écrans mais malheur, le second m’affiche n’importe quoi, le test fait planter l’application et tout le bazar. Soit dit en passant, je n’ai jamais réussi à booter ce linux avec le kernel installé par Gutsy (2.6.22), j’étais en 2.6.20 à ce moment là.

Ensuite je me suis dit, mouais, j’ai vraiment pas de temps à perdre là, depuis le temps que j’hésite, je lance une installation d’OpenSuse 10.3 dont j’avais un cd à portée de main (pas sur la même partition). Tout va bien dans le processus jusqu’à l’installation de Grub qui ne veut rien savoir. Et là, malheur des malheurs j’ai tenté d’installer Lilo à la place. Il veut pas non plus. Je redémarre (sans avoir pu achever l’installation mais en interrompons proprement. Et là : trop cool !! Grub m’affiche juste un message d’erreur 17. Génial.

En gros tout est inutilisable, tout. Ubuntu. OpenSuse. Windows XP. Tout.

Bon évidemment, je ne panique pas. Je fouille mon tiroir où traine une bonne dizaine de Live CD et autres et je commence à essayer. Y a rien qui boot, j’essayais une installation de Debian : pas de disque dur installé sur la machine. Je tente une installation d’OpenSuse sur une clef usb de 2 go comme c’est gentillement proposé par l’installateur mais il m’annonce fièrement qu’il n’a pas réussi à formaté la clef (j’ai constaté que maintenant non seulement je ne peux pas la formater (menfin, on verra ça….) mais en plus elle fait plus que 8 mo. Bref je ne peux rien faire.

Face à cet échec j’ai cherché à rétablir Grub. Live CD (en mode console, décidemment…), retouche de Grub et ça repart mon kiki… enfin presque, seulement Windows XP. C’est cool, mais ça ne suffit pas. Depuis quelques jours il ne veut plus de mes cartes wifi, comme ça boum, indigestion. Donc ça ne me suffit pas un OS sans internet. Mais depuis Win XP j’ai lancé l’installateur d’OpenSuse 10.3 et je n’ai pas eu d’erreur critique durant son installation.

Pas d’erreurs non… sauf lorsqu’il se lance après l’installation, là X refuse de démarrer et sans rien laisser dans les logs. C’est super cool dis voir, je commence à m’éclater.

Je fais un petit break en testant ce que vaut un logiciel de partitionnement que j’avais payé presque aussi cher que Partition Magic : il m’annonce qu’il y a pas de disque dur sur ma machine (alors que les tests du Bios m’indique que tout va bien madame la marquise) et il est incapable de faire la moindre fonctionnalité proposée (que ce soit le soft proprio ou les outils linux embarqués).

Durant ce temps, j’ai fini de télécharger l’iso d’ubuntu 7.10 (à une moyenne de 45 ko/s…) que je grave illico. Là ça démarre, mode graphique et tout, direct du 1680×1050 sur le 22″, on apprécie le geste. Par contre toujours pas moyen d’installer (ça bloque au partitionnement) et toujours pas moyen de configurer le second écran (mais y sert à quoi ce truc pour se simplifier la vie ??). Pas grave, je modifierai xorg.conf plus tard.

Donc je n’ai pas installé mais en bidouillant /etc/network/interface j’ai pu connecter le wifi (je signale au passage que sur toutes les installations linux que j’ai vu passer aujourd’hui il n’y a que Debian Sarge (mes lecteurs ne voulaient pas booter sur l’iso Etch…) qui proposait de configurer du wifi, tout le reste c’était uniquement eth0…).

Donc ce matin j’avais :

• Windows XP
• Ubuntu 7.04

Qui marchaient et après une journée passée à installer/paramétrer j’ai :

• Windows XP
• Ubuntu 7.10 en live

C’est mieux que rien mais ça me bloque trop de trucs. Il est évident que j’ai un problème sur cet ordinateur, disque dur trop foireux (soit c’est le disque dur qui a de la peine avec les formatages, soit c’est toutes les distributions linux qui ont de la peine avec le formatage…) et en tout cas un lecteur optique qu’il faut changer (le second est récent).

Morale : Plusieurs choses, mais ce que je constate et qui est important pour moi c’est que les distributions courantes (Ubuntu/OpenSuse) deviennent presque usine à gaz que Windows et c’est bien dommage. Je préfère un système qui est extrêmement simple (mais robuste) afin d’implémenter dessus ce qui est utile et uniquement utile, j’ai pas besoin du millier de paquets qu’installe ubuntu lors d’un changement de version.

Donc je vais sérieusement envisager de faire une croix sur ces systèmes qui ne me satisfont plus pour migrer sur du Debian Etch, Slackware ou encore Linux from scratch dès qu’un disque dur fiable sera là (demain je pense). Auriez-vous des conseils/remarques à ce sujet ?

ps : Au cas où une partie semble incohérente merci de le signaler. Lorsque j’écrivais la conclusion j’ai fait quelques backspace ce qui a abouti à une petite suppression impromptue de plusieurs lignes dont j’ai retrouvé quelques mots au milieu du post. Les joies des LiveCD…

—————————

Edit du 20/10/2007 : Voilà, nouveau disque dur installé. Installation propre dessus de Ubuntu 7.10 (en gros ce que j’avais à portée de main ce moment là) et pas de soucis. D’ailleurs chapeau pour garder les paramètres wifi entre le LiveCD et l’installation… alors que sous 7.04 il fallait rentrer la clef tous les deux démarrages.

Par contre j’ai toujours des petits problèmes avec le dual-screen (je ne sais pas comment il calcule le 1280*1024 mais ça tient pas sur le 17″…). Il ne veut pas activer les effets 3D mais ça tant mieux.

Un ami m’a recommandé de tester OpenSuse 10.3, promis je le ferai mais pour l’instant je vais profiter un peu de cette installation avant de tout casser à nouveau.

Navigateurs exotiques

En regardant de près les statistiques de Daskoo (qui va super bien soit dit en passant), mon attention a été retenue par les détails des navigateurs et leurs versions.

On parle toujours de deux principaux : Firefox et Internet Explorer mais développer un site pour eux ne suffit pas. Ce qui va suivre démontrer une fois de plus l’importance d’avoir un site accessible avec des alternatives à Flash/AJAX.

Pour commencer avec Firefox et IE, comme je l’ai dit il y a un gros pourcentage de FF 2.0 et IE 6/7 mais il y a aussi…

Ok mais il y a encore ceux qui ne sont ni FF ni IE… comme Netscape (nan il est point mort)

Bon, qu’est-ce qu’il nous reste… simplement le pire car il y a une variété époustouflante et ça représente tout de même 6% des visiteurs…

Est-ce que tout ce beau monde voit convenablement le site ? Daskoo n’est pas un site complexe, mais il faut supporter CSS 2 pour le voir correctement, et CSS 2 tous les navigateurs cités dans ce billets ne le supporte pas. Vous aussi vous avez des navigateurs « exotiques » non ? Que faites-vous pour eux ?

Qui veut rouler sur la lune ?

Il y a deux jours, le 14 septembre 2007, Google annonçait discrètement qu’il soutenait le prix X Prize de la fondation du même nom. Comment fonctionne ce prix ?

L’idée est de fixer un défi au secteur privé (le soutien par des gouvernements n’est pas possible), d’ailleurs selon le règlement 90% au moins des fonds doivent provenir du privé pour être conforme, et récompenser largement le gagnant.

Si le prix est imposant (20 millions pour le grand prix cette fois et 10 millions lors de la dernière édition), le défi l’est tout autant :

• Lors de la dernière édition remportée en 2004 par SpaceShipOne, il fallait réaliser des vols sub-orbitaux à 100 km d’altitude.
• À présent le défi est d’envoyer un robot faire une petite promenade de 500m sur la lune en envoyant des images et communications en quasi temps réel.

X Prize vise entre autre à relancer l’intérêt général pour le domaine spatial, les mathématiques et autres sciences.

Selon le communiqué de Google, ils espèrent avoir 6 ou 7 participants crédibles. Pour toucher les 20 millions de dollars, il va falloir faire très vite car dès 2013 le prix perd 5 millions. À noter qu’un prix secondaire ainsi que des bonus sont également en jeux, totalisant 5 millions (donc 30 millions de dollars pour la totale):

• Prix secondaire si le robot ne fait qu’envoyer des images
• Bonus si le robot fait plus de 5km (10 fois plus que demandé par le prix principal)
• Bonus si le robot rapporte des photos des missions précédentes (allusion aux missions Apollos ? Si des images sont rapportées ça risque de faire du mal à la polémique en cours depuis longtemps…)
• Bonus si le robot résiste aux durs conditions de la lune (froid glacial durant la nuit) durant deux semaines

Bien que le prix soit imposant, il ne couvrira pas forcément les frais de développement, surtout si le prix remporté n’est « qu’un bonus ». Par contre cela fait une formidable publicité et carte de visite pour le créateur (voir la médiatisation pour SpaceShipOne et les retombées que cela aura lorsque Virgin lancera prochainement son agence de vols spatiaux).

Ce que je trouve dommage c’est l’esprit du concours : « On envoie sur la lune, on émet des signaux et c’est finit pour le robot. » Il va donc rester sur la lune en compagnie de base de module spatiaux, instruments, mirroirs, jeep et autres restes des missions lunaires.

C’est marrant, on a fait à peine quelques missions humaines sur la lune et lors du retour d’humains là-bas (projeté en 2020 par la NASA), la lune est déjà un dépotoir.

Au mois lors du défi des vols orbitaux, l’enjeu était de concevoir un véhicule réutilisable. C’est pour cela que le défi n’est véritablement intéressant que si au minimum on s’intéresse à tous les prix : endurance, fiabilité,… les robots envoyés sur mars dépassaient régulièrement leur espérance de vie (à part les échecs).

Étant participant à l’Eurobot 2008, je connais l’intérêt et les enjeux de ce genre de concours et c’est extrêment intéressant au vu du nombre de défis à résoudre (lancement, communication, déplacement, autonomie, solaire, etc… surtout à 300′000km de distance…).