VM SQL Server 2012 sur Azure : Performance disque avec SQLIO

Après avoir créé note machine virtuelle sur Windows Azure il est temps de procéder à quelques tests de performance. Notre VM est dotée de 8 cœurs et 14 GB de mémoire vive. Bien des serveurs aujourd’hui en production sont bien moins pourvus !!! Même si je rencontre des machines dotées de 24, 32 ou 64 cœurs, avec 128, 256 ou 320 GB de RAM (oui, j’ai cette chance ), la configuration extra-large proposée dans Azure permet de travailler sérieusement, même si j’aurais aimé plus de flexibilité en ayant la possibilité de choisir la quantité mémoire pour par exemple monter à 32 GB de RAM.

Mis à part le problème liée à la consommation excessive de mémoire liée à SSRS facilement résolu, je n’ai pas encore eu l’occasion de me pencher en détail sur la configuration de la VM ni de SQL Server.

Avant toute mise en production, vous vous devez d’avoir testé les performances de votre machine. Pour SQL Server, le sous-système le plus critique au niveau de la performance est sans conteste les disques. Plus votre sous-système disque sera performant, plus votre serveur SQL sera performant. Même si toutes les requêtes SQL travaillent en mémoire (mise à part RESTORE DATABASE) en accédant au buffer pool, il reste que tout ne peut pas forcément tenir en mémoire et que des accès au disque vont être nécessaire :

• La base TempDB pour tout ce qui touche au version store, l’écriture de données liés à vos tables temporaires, le spool de données temporaire pour des tris ou des jointures ….
• Vos bases de données et plus particulièrement l’écriture dans le journal de transaction dont la latence disque va être un facteur primordial de performance …

Pour bencher vos disques, vous avez le choix : ATTO, IOMETER, SQLIO …

Le test avec SQLIO :

Pour ce test et afin de mesurer a la fois les IOPS et la latence, je vais travailler avec SQLIO. J’ai défini un fichier de 10 GB (ce n’est pas énorme, mais sachant que je ne connais pas la taille des caches sur les contrôleurs des baies de disque, il faut bien donner un taille).

Pour un test réel en production, je recommande une durée (par test) de 5 à 10 minutes. Ici, pour gagner un peu de temps, j’ai choisi de ne faire durer chaque test que 2 minutes, en espérant que ces mesures soient représentatives de la performance réelle du disque. Je pense pas non plus qu’il y ait une garantie quelconque de maintient de ces performances dans le temps, lorsque la plateforme Azure pour les machines virtuelles sera en rythme de croisière avec une charge conséquente sur les Hyper-V (oui, c’est bien Hyper-V qui se cache derrière comme le montre la liste des services et les “additions”).

Déjà, on peut noter que l’on dispose de 1.3 TB de stockage pour cette VM. C’est une bonne chose pour mettre en place des bases d’une certaine volumétrie. Par contre, le formatage du disque utilise des tailles de cluster de 4KB (la valeur par défaut pour un Windows 2008 R2).

Même si la virtualisation a tendance à niveler les différences de performance liées aux tailles de cluster (SQL Server travaille avec des IO de 64 KB), je préfère encore aligner mes IOs. On va voir si le test avec SQLIO nous en dis plus long.

Une fois le fichier résultat complet, il est temps de l’analyser. Pendant que le test était en cours, une première indication plutôt positive : jusqu’à 5 GB / Sec !!!

OK, pas mal et le nombre d’IOPS ? La latence ?

Les résultats :

Là aussi, on est sur de très bonnes perfs. Près de 65 000 IOPS en read random 64 (vos accès en lecture, sauf si vous faites des cluster index scan ou table scan). Avec une latence proche de zéro !!! Cool. On est à plus de 4GB à la seconde !!!

Je ne m’explique pas la latence des accès max (alors que l’average est a quasiment à zéro) pour des blocks de 8 et 32 KB. Que nous dit PAL ?

Comme l’on pouvait s’y attendre, il y a de la file d’attente disque, de 3 à 5GB de bande passante, et finalement peu de latence en moyenne.

Durant le test, la CPU a été un peu sollicitée, normal, mais j’ai aussi vu certains processeurs parkés de temps à autres.

Et on retrouve les valeurs des reads/sec et de writer / sec issues du SQLIO

et les latences

Bilan

De bonnes performances, voire très bonnes performances ( ) donc … Au niveau de baies de disques de haut vol. Il faut vraiment espérer que ces mesure soient toujours valables dans quelques mois …

Note : Alors que j’écrivais les quelques lignes de ce billet, j’ai relancé une batterie de tests avec un fichier de 50 GB et une durée de 5 minutes pour chaque action du SQLIO. Les résultats sont comparables.

avec une bonne bande passante (on distingue assez facilement les paliers correspondants aux tailles des IO issus du test)

 

Pour conclure, je dois avouer que j’ai été plus que surpris par le niveau de performance des disques dont sont pourvus les VMs. Je ne peux pas dire si la taille de la VM en nombre de cœurs et en quantité de mémoire influe sur les choix de stockage des volumes associés aux VMs (j’essaierais de mesurer cela sur une autre VM de taille réduite). Je ne peux pas non plus dire si la charge globale des baies de disque risque de faire chuter ces métriques.

Mais cela laisse tout de même présager  de bonnes performances pour SQL Server et pourrait bien convaincre les plus réticents à tester cette offre Windows Azure, si ce n’est à l’adopter.