Azure : Tests de performance des disques (2ème Partie)

Il existe plusieurs utilitaires pour simuler une charge de travail sur les disques durs d'un serveur. Les plus connus sont Crystal Mark, IOmeter, SQLIO et mon préféré Diskspd

Je ne veux pas écrire un article afin d'expliquer comment utiliser l'outil puisqu'il en existe suffisamment sur le web. Je recommande Getting Started with Diskspd et Using Microsoft DiskSpd to Test Your Storage Subsystem.

Avant de commencer mon test, je veux expliquer mon but. En fait, j'ai deux objectifs. Le premier est de savoir si je peux obtenir 20 000 IOPS comme promis. Cependant, le nombre d'IOPs est non pertinent lorsqu'il n'est pas associé à un délai de latence. C'est pour cette raison que mon deuxième objectif est de savoir combien d'IOPs je peux obtenir avec un délai de latence très faible dans un contexte SQL.

Commençons les tests. Voici la commande que j'ai utilisée:

diskspd.exe -b64K -d60 -o32 -t8 -h -r -L -w0 -c20g E:\Temp\iotest.dat > C:\diskspd\iotest.txt

-b64K: Grosseur des blocs. J'ai formaté mon disque avec des blocs de 64K. SQL lit les données en bloc de 64k. Donc, je vais faire mon test avec des blocs de 64K :)

-d60: Durée du test, 60 secondes est suffisant.

-o32: Queue Lenght. SQL performe plusieurs petites opérations rapidement. Un Queue Lenght entre 8 et 32 est ce qui se rapproche le plus de SQL.

-t8: Nombre de thread. Je commence toujours avec un thread par coeur.

-h: Désactive la cache logicielle et matérielle en écriture

-r: Random. Oui pour le disque de données et tempdb. Non pour le disque de log.

-w0: Read/Write. 0% write, 100% read dans ce cas-ci. Ensuite je vais faire un test 25% write, 75% read. C'est selon vos besoins.

-c20g: Grosseur du fichier pour effectuer le test. 20GB est normalement suffisant. 

Résultat de mon premier test:


Wow, je suis très loin des 20 000 IOPs ! En plus, le délai de latence en moyenne de 62ms ! 

Perfmon me donne exactement le même résultat en terme de latence:



Je dois avouer que ma combinaison de 8 threads qui lit des blocs de 64K avec une queue lenght de 32 est une charge importante. En revanche, j'effectue seulement un test de lecture!

J'ai fait plusieurs tests avec différente combinaison. J'aurais aimé faire un beau tableau avec des barres et des couleurs, mais pour aujourd’hui ce sera seulement une image de ma feuille Excel :)


La première chose dont je constate est que les performances sont bien meilleures avec les blocs de 8K. Ce qui est bien normal.

Ensuite, les résultats sont très similaires entre les tests de lecture et d'écriture. C'est surprenant.

Ensuite, on remarque que le système atteint un maximum de 4082 IOPs lorsqu'il lit ou écrit des blocs de 64K. J'en retiens que si vous formatez vos disques avec des blocs de 64K, vous allez obtenir environ 25% des IOPs versus 8K. 

Le nombre de thread affecte beaucoup le délai de latence. La question est de savoir combien de thread SQL accèdent les disques simultanément. 

Le délai de latence n'est pas exceptionnel lorsque SQL lit ou écrit des blocs de 64K. Évidemment, plus la charge est élevée, plus le délai de latence augmente.


Conclusion:
  • Oui, je suis capable d'atteindre plus de 20 000 IOPs !
  • Selon mes tests, j'obtiens 5000 IOPs avec 8 millisecondes de délais si mon serveur SQL exécute un seul thread. Ensuite, les performances se dégradent.
Okay, c'est bien amusant tout cela, mais qu’est-ce qu’on en fait avec Dynamics AX ?

Previous
« Prev Post