Après avoir utilisé un serveur RPS durant 1 an, j’ai choisi de migrer sur un serveur Kimsufi. Le serveur RPS n’est pas mal mais le disque pose problème : il y a le principe du disque partagé à la bande passante vraiment trop limitée d’une part et la taille de ce disque elle aussi trop contraignante d’autre part.
Le serveur RPS offre un processeur normalement un peu plus rapide (double coeur et fréquence plus élevée) mais dont l’usage semble vraiment limité par le disque pour un usage web faisant appel à une BDD.

Le but de cet article est donc de comparer la performance avec mes petits outils habituels : bonnie++ et lmbench

Test du disque

• Seq Out Char : Kim ( 33 M/s ) – RPS ( 5 M/s )
• Seq Out Blk : Kim ( 50 M/s ) – RPS ( 6 M/s )
• Seq In Char : Kim ( 38 M/s ) – RPS ( 4.7 M/s )
• Seq In Blk : Kim ( 106 M/s ) – RPS ( 5.7 M/s )
• Rand. Seek : Kim ( 186 /s ) – RPS ( 113 /s )

Avec un facteur de l’ordre de 10, il est clair que la performance du serveur kimsufi est très loin devant celle du RPS. La perf du RPS est de l’ordre de celle d’un disque NFS sur reseau 100Mb ; soit de l’ordre de 2 fois moindre qu’un disque USB suivant d’autres tests que j’ai pu réaliser. La performance du disque Kimsufi est conforme à des tests effectués sur des disques classiques sata. Ce facteur limitant impacte fortement les performances d’accès à la base de donnée par exemple ; pour le reste, sur un serveur web, hors temps de backup c’est moins critique.

Test du processeur

• Fork de process : Kim ( 271 ms ) – RPS ( 191 ms )
• Exec de process : Kim ( 1042 ms ) – RPS ( 654 ms )
• Calcul int add : Kim ( 0.38 ns ) – RPS ( 0.48 ns )
• Calcul int mul/div : Kim ( 0.38/23 ns ) – RPS ( 0.19/20.5 ns )
• Calcul double add : Kim ( 2.26 ns ) – RPS ( 1.91 ns )
• Calcul double mul/div : Kim ( 3/17 ns ) – RPS ( 1.93 / 10.4 ns)
• 16p/64K Context switch : Kim ( 24 ms ) – RPS ( 22 ms)
• Latence TCP : Kim ( 35 us ) – RPS ( 25.2 us)
• Local comm – TCP : Kim ( 126 M/s ) – RPS ( 474 M/s )
• Local comm – Bcopy : Kim ( 572 G/s ) – RPS ( 1.1 G/s )
• Local comm – mem rd : Kim ( 2.2 G/s ) – RPS ( 2.5 G/s )
• Local comm – mem wr : Kim ( 0.9 G/s ) – RPS ( 1.5 G/s )
• Memory lantency L1/L2/Main/Rand: Kim ( 1.5/25/70/426 ns ) – RPS ( 1.4/8.1/62.5/180 ns )

Comme convenu la performance du Celeron est en dessous de celle de l’atom d’une génération plus recente avec une fréquence plus élevée et surtout un double coeur. N’empêche que l’écart entre les deux n’est pas d’un facteur 10 pas de 30 à 50% surtout lié aux accès mémoire.

Reste à tester mysql ; pour se faire j’ai utilisé myBench un petit outil tout simple en php :

• Create 500k record : Kim ( 138 s ) – RPS ( 34 s)
• Create md5 record / s : Kim ( 3300 ) – RPS ( 12949 )

Résultat plutôt surprenant où je m’attendais à ce que le kimsufi soit largement devant … une petite vérification des fichiers de conf s’impose ! à moins que ce ne soit le bench qui ne travaille que dans le cache …
Voyons donc avec sql-bench qui est distribué avec mysql et couvre plus de tests: (perl run-all-tests –server=mysql –user=.. –password=.. apres avoir créé une base ‘test’ sur mysql)

• Alter : Kim ( 15s ) – RPS ( 49s )
• Big-Table : Kim ( 10s ) – RPS ( 7s )
• Connect : Kim ( 289s ) – RPS ( 121s )
• Create : Kim ( 119s ) – RPS ( 4680s estimé )
• Insert : Kim ( 2183s ) – RPS ( 581s estimé )
• Select : Kim ( 141s ) – RPS ( 58s )
• Update with key : Kim ( 159s ) – RPS ( 28s )

Etrange comportement du RPS sur les creation de table, j’imagine que celles-ci demande beaucoup d’I/O. Les requetes de select et insert sont beaucoup plus rapide. Ma config ayant beaucoup de cache (pour plier au probleme de disque) la puissance CPU semble prendre le dessus sur les requete insert/select/update et ce avec un facteur important de l’ordre de 2 à 3. Il semble donc, et c’est avec surprise, que la config RPS soit meilleure pour les accès bdd, ce qui pour le coup m’ennuie. On note toutefois que dès lors que l’on sort des conditions optimales, le test n’est pas du tout linéaire …

Voici donc quelques détails supplémentaires avec 1.5M de lignes à traiter:

• Insert 3×1.5M : Kim ( 705s ) – RPS (146s )

Rien de bien neuf donc… si limite il y a dans la rupture de linéarité, elle est bien au dela des 1.5M de lignes.
Au final, une fois les sites migrés, je constate, à l’aide d’une sonde woozweb, que le temps de chargement moyen du site est 2 fois plus lente avec un KimSufi qu’avec un RPS, mais reste totalement acceptable, situant mes site dans la trache où 40% des sites font mieux pour du java et 9% pour du php basique.

Question du jour alors que j’envisage de remplacer ma machine par une version VIA EPIA equipé d’une compact flash en guise de disque dur… A quelle vitesse tourne mon disque actuel !

Voici donc quelques commandes utiles pour répondre à cette question:

• hdparm -t /dev/hda donne la vitesse d’accès en lecture sur le disque, toutefois, cette commande est un maximum car les conditions choisies par hdparm sont particulières. Dans mon cas, je trouve 30MB/s
• L’outil seek dont le source est ici permet lui de donner le plus mauvais cas, on multipliera le nombre de seek par 4 pour obtenir le nombre de KB/s. Dans mon cas, je trouve 220KB/s avec un temps d’accès de 32ms.
• Avec hdparm -T /dev/hda il est possible de voir ce que donne une lecture dans le cache. pour ma part j’obtiens 206M/s

Les paramètres de hdparm sont un point primordial dans l’optimisation des accès disques. hdparm /dev/hdales résume:

• multcount : indique combien de secteur sont rappatriés à chaque E/S
• I/O support : indique si le mode d’accès est 16, 32 ou 32-async
• unmaskint : indique si le noyau peut traiter d’autres interruption durant un accès disque
• using_dma : indique si l’usage du DMA est activé.. primodial !

Un autre outil pour les tests d’I/O est bonnie, dans sa version plus récente Bonnie++. Cet outil permet de tester les I/O d’une machine unix en testant les accès par bloc, caractère par caractère, testant les relecture et le temps d’accès. Il semble que ce soit l’outil le plus complet. Avantage de cet outil : il n’utilise par directement le périphérique mais le répertoire courant, du coup il est possible de tester un montagne NFS par exemple.
Mes résultats sont les suivants:

• Montage NFS (100Mb)
  • Mode char WR/RD: 9MBs / 7MBs
  • Mode block WR/RD: 9MBs / 7.5Mbs
  • Rewrite : 4MB/s
  • Seek : 130/s
  • File seq created /s : 80
  • File seq Read /s : 3791
  • File seq Deleted / s : 164
  • File rand created /s : 91
  • File rand Read /s : 5395
  • File rans Deleted / s : 132
• Disque local:
  • Mode char WR/RD: 21MBs / 25MBs
  • Mode block WR/RD: 35MBs / 26Mbs
  • Rewrite : 13MB/s
  • Seek : 123/s
  • File seq created /s : 22144
  • File seq Deleted / s : 25867
  • File rand created /s : 22825
  • File rans Deleted / s : 22231