Evaluer le Resource Governor de SQL Server


Bonjour à tous,

Les versions récentes de SQL Server offrent la possibilité d’introduire des notions de Qualité de Service vis à vis de certaines ressources : IO, RAM, CPU, par la fonctionnalité ‘Resource Governor’.

La création d’un algorithme gérant l’allocation ou non de ces ressources n’est pas aussi triviale qu’il n’y parait (je vous laisse découvrir son petit monde de complexité sur le Web).

Dans le contexte de SQL Server, cet algorithme doit de plus s’intégrer au contexte du scheduling coopératif qui préside à l’exécution des worker threads : en gros l’algoritme ne peut pas se contenter d’interrompre tout SPID qui a dépassé son quota car il n’est pas pré-emptif. Au lieu de ça, il agit à des ‘checkpoints’ et doit décider à ce moment si le thread peut continuer ou pas sur la base d’une estimation de sa consommation future en ressource pendant le prochain cycle (jusqu’au prochain checkpoint, qui est décidé par le code qu’exécute le thread et non pas par l’algorithme, qui de plus n’a aucune visibilité sur cette échéance). Multiplions ça par n threads travaillant dans plusieurs groupes différents avec des quotas hauts et bas différents. Tout de suite moins simple, n’est-ce-pas ? :)

Sans rentrer plus dans les détails, le fait est que les algorithmes implémentés vont ‘tendre’ vers les valeurs cibles configurées par le DBA dans le resource governor. Cependant ils pourront d’autant plus s’en rapprocher qu’ils brasseront une quantité importante de SPID à activités variées. Si très peu de SPID sont actifs à un instant t, il y a des chances qu’il soit impossible d’obtenir la granularité qui permette de s’approcher de manière fiable des valeurs cibles.

Un peu comme si vous deviez remplir un car de 50 places sans pouvoir séparer les groupes de passagers :  c’est plus facile en travaillant avec de nombreuses familles de tailles diverses qu’avec 3 ou 4 colonies de vacances complètes.

Cet élément établi, revenons dans le contexte d’un DBA découvrant cette fonctionnalité. Son premier reflexe sera de la tester afin de voir si elle répond à ses besoins. Et ce test consistera très certainement a créer 2 groupes, puis un SPID dans chacun ayant une activité lourde vis à vis de la ressource arbitrée. Et donc de prendre complètement à revers l’algorithme :) Vous ne serez donc pas étonnés si je vous dis que les résultats d’un tel test risquent d’être décevants, avec des groupes de ressources ne se conformant pas aux limites mises en place. Avec un peu de malchance une des activités fera un usage artificiellement poussé de fonctions intensives qui rendent plus rarement la main au scheduleur que le SPID lambda, ce qui scellera le verdict.

Donc, amis DBA, si vous décidiez d’explorer le Resource Governor de SQL Server, évitez les colonies de vacances et assurez-vous de créer un jeu de test représentatif d’un serveur actif, c’est à dire comprenant un nombre conséquent de SPID associés à des tâches variées, ce qui donnera aux algorithmes assez de matériau pour produire un comportement conforme à vos attentes.

A bientôt,

Guillaume Fourrat

Ingénieur d’Escalade

Microsoft France

Comments (0)

Skip to main content