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 Smile), 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).

imageimage

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.

imageimage

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 !!!

image

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

Les résultats :

image

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 !!! Smile

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 ?

image

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.

Processor_Percent_Processor_Time_Total_1

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

LogicalDisk_Disk_Reads_sec1LogicalDisk_Disk_Writes_sec1

et les latences

LogicalDisk_Avg_Disk_sec_Read1LogicalDisk_Avg_Disk_sec_Write1

Bilan

De bonnes performances, voire très bonnes performances ( Smile ) 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.

image

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

LogicalDisk_Disk_Bytes_sec1image

 

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.

A propos Christophe

Consultant SQL Server Formateur certifié Microsoft MVP SQL Server MCM SQL Server 2008
Cet article, publié dans Windows Azure, est tagué , , . Ajoutez ce permalien à vos favoris.

5 commentaires pour VM SQL Server 2012 sur Azure : Performance disque avec SQLIO

  1. tomconte dit :

    Bonjour,
    Ces tests ont-ils été effectués avec les disques locaux? Il faut faire attention au fait que ces disques ne sont pas persistants : leur contenu disparait si l’on détruit la VM… Pour des données persistantes, il faut ajouter un ou des disques supplémentaires via le portail, qui seront stockés dans des Blobs et donc indépendants de la VM.

  2. Christophe dit :

    Bonjour,

    J’ai testé le volume rattaché par défaut avec la VM, effectivement il se peut tout a fait que le stockage temporaire soit détruit lorsque l’on supprime la VM, ce qui en soit ne me dérange pas spécialement. Un reboot ne supprime pas les fichiers de ce volume « temporaire », car il est bien libellé ainsi. Je vais relancer quelques tests avec un disque persistant pou voir ce que cela donne. En espérant que je ne me fasse pas trop remarquer, depuis que j’ai stoppé mes tests sur la VM 8 coeurs / 14 GB de RAM, il ne m’est plus possible de la démarrer. On m’invite seulement à supprimer la VM !!!

  3. Ping : VM SQL Server 2012 sur Azure : SQLIO suite | Christophe LAPORTE – Consultant SQL Server

  4. Ping : 16 volumes Windows Azure : le test SQLIO | Christophe LAPORTE – Consultant SQL Server

  5. Ping : VM Amazon HI1 : performance disque avec SQLIO | Christophe LAPORTE – Consultant SQL Server

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s