Je profite d’un petit moment de libre pour écrire un billet sur un problème de performance que j’ai pu constater il y a quelques avec SQL Server et une baie SAN HP EVA 4000 dans un milieu virtualisé et VMWARE. Je place rapidement le décor : je dois intervenir pour un problème de performance SQL Server. Le client m’explique un peu son architecture et me dit que son instance SQL Server est virtualisée. Les applications qui tournent sur ce serveur ont visiblement des temps de réponse assez important.

En plaçant judicieusement les compteurs de performance et en regardant les DMV adéquates je m’aperçois rapidement que le problème vient du stockage. Les temps de réponse annoncés sont de l’ordre de la seconde voir de la dizaine de seconde à certains moments. Je dis à mon client que le problème se situe entre SQL Server et son stockage. Je commence à regarder le paramètre de file d’attente de la carte HBA et je m’aperçois que celle-ci avait une valeur que l’on retrouve habituellement dans les configuration de serveur de bases de données à savoir 64 . Entre temps un de mes collègues (consultant sénior sur la virtualisation) regardent les paramètres de fil d’attente sur VMWARE et s’aperçoit que les valeurs diffèrent avec celles de la carte HBA. Après avoir corrigé le tir la situation va enfin revenir à la normale. Les temps de réponse du stockage sont alors de la milliseconde.

Ok on a la solution mais tentons de comprendre pourquoi nous avons eu ce problème :

Tout d’abord définissions le rôle d’une file d’attente avec les cartes HBA. Des commandes SCSI sont envoyés au stockage (donc aux disques) pour pouvoir lire et écrire les données. Cependant pour éviter que le sous-système disque soit engorgé par un nombre important de ces commandes, celles-ci peuvent être placés dans la file de la carte HBA pour être traitée ultérieurement. Le paramétrage de profondeur de la file d’attente permet de contrôler le nombre de commande qui peuvent y être présentes. Le fait d’augmenter cette valeur peut permettre une certaine optimisation d’autant plus que SQL Server est une application plutôt consommatrice d’I/O.

Cependant n’oublions pas qu’il existe une couche supplémentaire entre le système d’exploitation et la carte HBA dans notre cas vu que nous sommes dans un environnement virtualisé. C’est donc l’ordonnanceur de VMWARE qui envoie ces fameuses commandes SCSI à la carte HBA. Il faut savoir que le VMKernel a lui aussi sa propre file d’attente pour pouvoir empiler les commandes SCSI simultanés provenant d’une ou plusieurs machines virtuels. La profondeur de cette file d’attente est contrôlée par le paramètre de configuration Disk.SchedNumReqOutstanding et est égale à 32 par défaut. Pour résumé nous avons une situation où les commandes SCSI sont transférés d’une file d’attente applicative gérée par VMWARE vers une file d’attente physique gérée par la carte HBA.

Que se passe-t-il si les valeurs de profondeur des différentes files d’attentes ne sont pas alignées ?

• Si le paramètre Disk.SchedNumReqOutstanding est plus petit que celui de la carte HBA alors nous ne bénéficierons jamais pleinement de la file d’attente de cette dernière.
• Si le paramètre Disk.SchedNumReqOutstanding est plus grand que celui de la carte HBA alors on aura l’effet inverse. On pourra constater un goulet d’étranglement au niveau de la file d’attente de la carte HBA. De plus dans la plupart des cas, il est rare d’avoir une carte HBA réservée à une seule machine virtuelle. Dans ce cas les commandes SCSI pourront s’entasser rapidement. On retrouve ce phénomène dans les cas de la vie courante comme lorsque nous sommes pris dans les bouchons de la circulation par exemple

VMWARE recommande d’avoir une valeur de 64 dans les 2 files d’attentes. Bien entendu la bonne valeur est celle que vous aurez pris soin de choisir par des tests en fonction de votre environnement mais il faut savoir que l’augmentation excessive de profondeur de file d’attente nuit paradoxalement aux performances. En effet, une file d’attente plus importante veut aussi dire un traitement plus long des IO et donc une latence beaucoup plus élevée.   Il faut donc trouver le juste milieu !!

Bonne virtualisation

David BARBARIN (Mikedavem)
MVP SQL Server