Voici une série d’article comportant 10 chapitres destinés à tout ceux qui veulent obtenir de meilleurs performances avec SQL Server… C’est à l’occasion des JO de paris, que j’ai eu l’idée de cette série d’articles sur les performances… Ou plus exactement comment remédier aux mauvaises performances de vos bases de données avec SQL Server, lorsque c’est le cas…

Il n’y a pas de fatalité. L’acquisition de bonnes performances est le résultat de l’application d’un ensemble de bonnes pratiques, de réglages, de paramétrage, de tuning, de maintenance, d’architecture et de choix matériel…

Microsoft SQL Server, grâce à ses outils conviviaux, donne l’impression d’une certaine facilité. Mais c’est un SGBDR poid lourd qui se trouve dans le peloton de tête des SGBD d’Entreprise et à égalité avec IBM DB2 ou Oracle Database, voire supériorité, notamment en matière de performance comparé à Oracle Database.
Rien à voir avec les SGBD « libres » comme MariaDB (en situation de faillite) ou PostGreSQL… dont les capacités sont naturellement limitées du fait d’un choix d’architecture pauvre et daté, nous en reparlerons au cours de ces articles. Il y a donc pas mal de choses à faire pour le rendre plus performant et parfois les gains sont spectaculaires…

CHAPITRE 1 : et la VM dans tout ça ?

Il y a quelques années (2010), Microsoft déconseillais l’utilisation de Machines virtuelle…

Limites de la virtualisation de SQL Server selon Microsoft en 2010

Mais aujourd’hui nombreuses sont les installations de SQL Server a être virtualisées… C’est pratique pour de petits et moyens serveurs. Cela permet de réaliser des économies d’échelles (encore que…) et de permettre la reprise dans le cadre d’un PRA notamment grâce aux snapshots de VM que l’on peut remonter rapidement sur un autre ESX…

Néanmoins il existe de nombreuses règles à respecter pour que les performances soient au rendez-vous.

Microsoft comme VMWare bottent tous les deux en touche lorsqu’on les sollicites sur des problématique de performances et votre instances de SQL Server est en VM. L’un accusant l’autre des mauvaise performances et se renvoyant la balle mutuellement avec au milieu un pigeon : vous !

Notez que si vous avez opté pour une virtualisation avec Hyper V, Microsoft vous aidera sans aucune limite… Mais la plupart des ingénieurs système préfèrent de loin VMWare, c’est plus puissant, plus grandiose, plus sophistiqué… donc plus complexe, plus confus et plus casse gueule !… Rares sont en effet ceux qui maitrisent parfaitement VMWare et je vous assure que je n’en fait pas partie, mais je que maitrise assez bien les problématiques de ce logiciel combiné à celui de SQL Server…
Et puis il y a le récent rachat de VMWare par Broadcom… et donc un changement de métriques dans le calcul des tarifs (passage du CPU au cœur ) avec une mise en œuvre immédiate et une ignorance volontaire de l’historique client. Bref une facture multipliée par 2 à 15... Tout cela se traduisant par des procès (Thalès, Orange, AT&T…) devant les tribunaux quand il n’est pas possible de migrer immédiatement vers une autre plateforme de virtualisation… Il semble que WMWare/Broadcom devrait être atteint par le  « syndrome Oracle » celui, au final, de recenser plus d’avocat que d’ingénieurs…

Sachez enfin qu’en cas d’appel à la ligne chaude (oui, je déteste les anglicisme pour des choses qui se traduisent facilement en français, mais ne devrais-je pas dire « assistance en ligne » ?) de Microsoft, l’ingénieur tentera de résoudre votre problématique SQL Server quelle qu’elle soit, mais si c’est sur une VM, il pourra vous demander de dé-virtualiser, reproduire le problème sur une machine physique afin de traiter votre demande…. C’est dans le contrat de licence !

0 – Le document de référence…

Microsoft comme VMWare en ont eu marre de traiter des demandes insatisfaites et les deux éditeurs se sont concertés pour produire un document officiel concernant la façon dont les VM hébergeant du SQL Server doivent être paramétrée…. Ce document intitulé « ARCHITECTING MICROSOFT SQL SERVER ON VMWARE VSPHERE » est disponible ici et est mis à jour régulièrement…. À date du 13 juillet 2024, l’édition 2019 comporte 83 pages…

Comme vous êtes faignants (si, si j’insiste, un bon informaticien doit être faignant. Ce qui apparait comme un défaut chez beaucoup est une qualité chez l’informaticien, car moins il en fait, mieux on se porte…) je vais vous délivrer quelques uns des points clés de ce qu’il faut faire…

Mais les principes de base sont simples :

• actionnez tous les paramètres qui permettent à votre VM d’être dévirtualisé;
• du côté de SQL Server agissez comme si votre instance n’étais pas sur une VM.

1 – Sockets, CPU, cœurs physiques et cœurs logiques

Il est tout d’abord important de savoir dans quelle édition de SQL Server est votre instance… par exemple avec la version 2022, les limites d’utilisation sont les suivantes :

• Enterprise licence serveur : pas de limitation
• Enterprise licence par utilisateurs : 20 cœurs
• Standard : 4 sockets et 24 cœurs (donc au plus 4 sockets de 6 cœurs)

En version standard il est donc impératif de ne jamais dépasser ces limites…. Hélas dans mes nombreux audits, je remarque généralement une inversion de ces chiffres. Il faut dire que l’interface de VSphere laisse à désirer…

VMWare VSphere réglage CPU

Dans cette interface vous ne devez jamais dépasser 4 CPU pour la version Standard et en principe pas plus de 6 cœurs par CPU… Ce réglage est donc faux pour la version standard, dans la mesure ou 12 cœurs ne seront jamais utilisés par l’instance SQL Server…

2 – Fréquence des CPU, licences et VM

Ce second sujet est loin d’être négligeable. Microsoft fait payer ses licences par rapport au nombre de cœurs… Mais tous les cœurs ne battent pas à la même vitesse (ou je sais, je suis un romantique…). La question est donc de savoir si vous voulez donner plus d’argent à Microsoft ou a Untel (pardon Intel…). Voyons alors quel est le coût des licences par paires de cœurs (curieusement, les cœurs vont toujours par paires dans les soquettes ! Alors que cela devrait être l’inverse… Deux soquettes parce que nous avons deux pieds mais un seul cours…. Oui, d’accord je fais encore mon romantique !). Donc, au 13/07/2024, les prix de SQL Server sont les suivants :

• Enterprise : 15 123 $ soit 12 049 € pour 2 cœurs
• Standard : 3 945 $ soit 3 622 € pour 2 cœurs

La question de la puissance de calcul doit donc être menée en ces termes :

• dois-je prendre moins de cœurs avec des CPU plus rapide ?
• dois-je prendre plus de cœurs avec des CPU moins rapide ?

Regardons maintenant ce que coûte un moderne processeur Intel Xeon, mettons par exemple un Xeon w7-2475X. Ce type de processeur comporte 20 cœurs et coute 1 800 $. Il tourne à la fréquence nominale de 2,60 Ghz. Si vous construisez une VM dotée de 8 cœurs physique votre puissance maximale de calcul sera de 20,8 Ghz… Mais vous activez le mode turbo, vous aurez une puissance maximale de calcul presque équivalente avec seulement 4 cœurs (19,2 Ghz) et vous économisez 7 244 € de licence SQL Server avec l’édition standard. Évidemment avec l’édition Enterprise la barre est nettement plus haute…

Vous avez donc tout intérêt à mettre dans vos ESX les processeurs les plus rapide qui soit pour économiser beaucoup l’argent des licences SQL Server.

Mais ce n’est pas tout… Encore faut-il faire en sorte d’activer le mode turbo des processeurs. Cela se fait à différents niveaux :

• au niveau du BIOS généralement pour agir sur le réglage hardware du CPU
• au niveau de l’ESX en activant le mode « High performance »
• au niveau de Windows en désactivant le mode « économie d’énergie »
• au niveau de la VM en faisant de la réservation de fréquence

Host Power Management must be set to HIGH in ESX

La quatrième ligne de l’écran VMWare VSphere réglage CPU montre que l’on peut indirectement réserver les CPU à la VM…. En effet, ces CPU peuvent être volés a cette VM pour fournir des ressources à une autre VM… or les bases de données sont les systèmes les plus consommateurs de ressources de toutes sortes (CPU, RAM, disque…).

Il convient donc de régler la réservation (en Mhz) en effectuant le calcul suivant :

Si vous avez activé le mode turbo et effectué tous les réglages pour qu’il soit pris en compte, vous pouvez utiliser la formule :

le coefficient 0.95 ou 0.90 laisse à la VM quelques ressources de CPU à l’hyperviseur pour qu’il puisse faire son boulot… Hé oui, la virtualisation c’est pas gratuit…

Mais il y a un hic…

Vous êtes sans doute intéressé pour faire du VMotion… C’est à dire permettre à une machine virtuelle victime d’un snapshot de se balader d’ESX en ESX, pour assurer une soi-disant haute disponibilité (c’est généralement pas comme cela qu’il convient de faire de la haute disponibilité avec SQL Server car il existe des moyens plus pointus, plus fiables et bien plus résilients…. À me lire !).

Or en réservant sur un ESX doté de processeurs rapides un volume de Mhz qu’un autre ESX doté de processeurs plus lents ne serait pas capable d’exciter, vous risquez de vous trouver dans une situation de famine système conduisant à l’impossibilité de rendre opérationnelles cette VM… Bref, vous rêviez de disponibilité et vous rendez vos VM indisponibles !

Bref, il faut avoir pensé à tout et architecturé globalement vos ESX et vos VM en formalisant un standard préalable pour vos équipement et tenter de ne pas en déroger…

À lire en complément : Performance Best Practices for VMware vSphere 7.0

Il faudrait aussi parler de NUMA… mais restons en là si vous le voulez bien… C’est déjà pas mal !

3 – Et la mémoire ?

Là aussi il faut se préserver du « ballooning » qu’exerce VMWare par défaut…

Le ballooning consiste à voler la mémoire assignée à une VM qui travaille peu pour la donner à d’autres VM qui en ont besoin.
Le problème est que SQL Server incorpore un système d’exploitation interne appelé SOS (SQL Operating System, pour lesquelles Microsoft ne donne que très peu d’explication et qui gère les threads, la RAM et les E/S disques) qui le rend aveugle de ce qui se passe aux étages supérieur. En gros si on lui dit que la machine possède 32 go de RAM, alors son processus attendra ces 32 Go de RAM si nécessaire, sans se douter qu’une partie de ces 32 Go a été transféré par VMWare à d’autres VM… Et là, certains processus ayant besoin de mémoire vont devoir attendre la restitution…

Il est donc fondamental d’obliger la VM à garantir que la RAM est toujours disponible a son unique profit en cochant la case « Reserve All Guest Memory »…

En matière de RAM, le besoin minimal pour faire fonctionner correctement un serveur SQL est de 8 Go… mais c’est très faible, car comme tous les systèmes de bases de données relationnelles, SQL Server effectue toutes les manipulation de données exclusivement en mémoire (le cache). Il en faut donc beaucoup… Mais cette quantité dépend de plusieurs facteurs :

• La volumétrie globale des données des bases
• le modèle de données : s’il respecte les règles de l’art, le besoin de RAM sera faible
• l’indexation : les index nécessitent beaucoup moins de place en mémoire que les tables
• le nombre d’utilisateurs concurrent : chaque utilisateur a besoin d’un espace logique de travail en RAM
• la complexité des requêtes : plus elles sont complexes plus elles consomment de l’espace pour pouvoir s’exécuter

Il est difficile de pouvoir dire à priori quel est la quantité idéale de RAM nécessaire. C’est pourquoi SQL Server dispose de plusieurs compteurs pour permettre de déterminer si l’on est confortable ou dans le cas d’un goulet d’étranglement (n’avez vous pas remarqué pour ce dernier mot la confusion que bien des gens font avec le goulot ? …).
Parmi ces compteurs, les plus intéressants sont :

• le taux de mise en cache (il ne devrait descendre en dessous de 90 % et rester en moyenne au dessus de 99%)
• La durée moyenne de vie des pages en mémoire qui devrait être au strict minimum de 2h, mais s’avère être confortable à plus de 4 voir 8h

Assurez vous aussi que le total de la RAM assignées aux machines virtuelles soit bien en dessous de la RAM de l’ESX… car il faut aussi un peu de RAM à l’hyperviseur pour fonctionner…

4 – Quid des disques ?

Là encore, les disques virtuels sont à proscrire…. Je sais, cela commence à ressembler à un catalogue décrivant qu’il ne faut pas virtualiser… Mais que croyez vous ? Que la virtualisation augmente les performances de SQL Server ? Toutes ces couches de virtualisation pèsent au final lourdement sur les performances… Comparons avec les jeux olympiques… Imaginez qu’au saut à la perche on demande à l’athlète de rajouter, à ses chaussures, des chaussons en plastique, qu’on lui fournisse une perche enveloppée de gutta-percha et que la barre soit recouverte d’une épaisseur de mousse synthétique… Croyez vous que les records seraient aussi haut ?

Pour ce dernier éléments, comme SQL Server assure grâce à son OS interne les routines d’écriture (il ne délègue ni écriture ni lecture physique à l’OS Windows – ou Linux, ceci afin d’aller plus vite trouver les emplacement des informations ou faire moins souffrir le stockage…) il lui faut que l’organisation du disque soit visible et exploitable. Donc pas de disques virtuels ni RAID par entrelacement (5, 6, 50, 60, DP…).  les meilleures performances sont obtenues par du « disk pass through »…

Ce n’est pas pour rien que le document d’architecture comporte de nombreuses pages à ce sujet…

5 – En conclusion…

Outre tout ce que nous venons de dire, un seul principe absolu à toujours respecter pour maintenir les performances : PAS DE SURRÉSERVATION DE RESSOURCES DANS L’ENSEMBLE DES VM SUR UN MÊME ESX !

SQLpro (a) SQLspot.com - Tel O6 11 86 4O 66
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
* Le site sur les SGBD relationnels et le SQL : https://sqlpro.developpez.com *
* le blog SQL, SQL Server, SGBDR... sur : https://blog.developpez.com/sqlpro/ *
* Expert Microsoft SQL Server, MVP(Most valuable Professional) pendant 14 ans *
* Entreprise SQL SPOT : modélisation, conseil, audit, optimisation, formation *