Pool de ressources de Resource Governor

S’applique à :SQL ServerAzure SQL Managed Instance

Dans SQL Server Resource Governor, une liste de ressources partagées représente un sous-ensemble des ressources physiques d'une instance du moteur de base de données. Le gouverneur de ressources vous permet de spécifier des limites sur la quantité d'UC, les E/S physiques et la mémoire que les demandes d'application entrantes peuvent utiliser avec le pool de ressources. Chaque pool de ressources peut contenir un ou plusieurs groupes de charges de travail. Lorsqu'une session est démarrée, le classifieur du gouverneur de ressources affecte la session à un groupe de charges de travail spécifique, et la session doit s'exécuter à l'aide des ressources attribuées au groupe de charges de travail.

Concepts relatifs au pool de ressources

Un pool de ressources, ou pool, représente les ressources physiques du serveur. Vous pouvez visualiser un pool comme une instance SQL Server virtuelle à l'intérieur d'une instance SQL Server. Un pool a deux parties. Aucune partie ne se chevauche avec les autres pools, ce qui permet de conserver un minimum de ressources. L'autre partie est partagée avec d'autres pools et prend en charge la consommation maximale de ressources possible. Les ressources de pool sont définies en spécifiant un ou plusieurs des paramètres suivants pour chaque ressource (UC, E/S physiques et mémoire) :

MIN_CPU_PERCENT et MAX_CPU_PERCENT

Ces paramètres correspondent aux valeurs minimale et maximale garanties de la bande passante moyenne du processeur pour toutes les demandes dans la liste de ressources partagées en cas de contention du processeur. Vous pouvez utiliser ces paramètres afin de déterminer l'utilisation prédictible des ressources du processeur pour plusieurs charges de travail, en fonction des besoins de chaque charge de travail. Supposons, par exemple, que les services des ventes et marketing d'une entreprise partagent la même base de données. Le service des ventes présente une charge de travail gourmande en ressources du processeur, avec des requêtes de priorité élevée. Le service marketing présente également une charge de travail gourmande en ressources du processeur, mais avec des requêtes de priorité plus faible. En créant un pool de ressources distinct pour chaque service, vous pouvez affecter un pourcentage minimal d'utilisation de l'UC de 70 pour le pool de ressources des ventes et un pourcentage maximal d'utilisation de l'UC de 30 pour le pool de ressources marketing. Cela garantit que la charge de travail Ventes reçoit les ressources du processeur dont elle a besoin et que la charge de travail Marketing est isolée des demandes du processeur de la charge de travail Ventes. Le pourcentage maximal d'utilisation du processeur est un maximum opportuniste. Si la capacité de processeur est disponible, les threads de travail l'utilisent entièrement, jusqu'à 100 %. La valeur maximale s'applique uniquement en cas de contention des ressources de processeur. Dans cet exemple, si la charge de travail Ventes est désactivée, la charge de travail Marketing peut utiliser 100 % de l'UC, si nécessaire.

CAP_CPU_PERCENT

Le paramètre CAP_CPU_PERCENT définit une limite maximale inconditionnelle d'utilisation de la bande passante de l'UC pour toutes les demandes exécutées dans le pool de ressources. Les charges de travail associées au pool peuvent utiliser la capacité du processeur au-delà de la valeur de MAX_CPU_PERCENT si elle est disponible, mais pas au-delà de la valeur de CAP_CPU_PERCENT. Partant de l'exemple de la section précédente, supposons que le département Marketing soit facturé pour l'utilisation des ressources. Il souhaite une facturation prédictible et ne veut pas payer pour plus de 30 % du processeur. Pour garantir cette exigence, il suffit de définir CAP_CPU_PERCENT à 30 pour la liste de ressources partagées du département Marketing.

MIN_MEMORY_PERCENT et MAX_MEMORY_PERCENT

Ces paramètres spécifient la quantité de mémoire minimale et maximale réservée à la liste de ressources partagées qui ne peut pas être partagée avec d'autres listes de ressources partagées. Pour des base de données sans tables à mémoire optimisée, la mémoire dont il est question correspond à la mémoire allouée à l'exécution des requêtes, et non à la mémoire du pool de tampons (des pages d'index et de données). Pour plus d'informations sur les allocations de mémoire d'exécution des requêtes, consultez Considérations relatives à l'allocation de mémoire. La définition d'une valeur minimale de mémoire pour un pool garantit que le pourcentage de mémoire spécifié est disponible pour toutes les demandes qui s'exécutent dans cette liste de ressources partagées. Ce paramètre est différent de MIN_CPU_PERCENT, car dans ce cas, la mémoire peut rester dans la liste de ressources partagées donné même si le pool n'a pas de demandes dans les groupes de charge de travail appartenant à ce pool. Il convient donc d'être prudent lors de l'utilisation de ce paramètre, car cette mémoire ne peut être utilisée par aucun autre pool, même s'il n'y a pas de demandes actives. Définir une valeur maximale de la mémoire pour un pool signifie que lorsque des requêtes s'exécutent dans ce pool, elles n'obtiennent jamais plus que ce pourcentage de mémoire globale.

Afin de régir la mémoire pour les tables à mémoire optimisée avec Resource Governor, vous devez lier la base de données à un pool de ressources distinct. Pour plus d’informations, consultez Lier une base de données avec des tables à mémoire optimisée à un pool de ressources.

AFFINITY

Ce paramètre permet de définir l'affinité d'un pool de ressources en fonction d'un ou de plusieurs planificateurs ou nœuds NUMA pour un niveau d'isolation supérieur des ressources du processeur. Pour reprendre le scénario des département Ventes et Marketing des sections précédentes, supposons que le service des ventes ait besoin d'un environnement plus isolé et qu'il souhaite disposer en permanence de 100 % d'un cœur du processeur. L'option AFFINITY permet de planifier les charges de travail Ventes et Marketing sur différentes UC. En supposant que la limite CAP_CPU_PERCENT est encore appliquée sur le pool marketing, la charge de travail Marketing continue à utiliser jusqu'à 30 % d'un cœur, tandis que la charge de travail Ventes utilise 100 % de l'autre cœur. Les charges de travail Ventes et Marketing s'exécutent sur deux ordinateurs isolés.

MIN_IOPS_PER_VOLUME et MAX_IOPS_PER_VOLUME

Ces paramètres correspondent aux valeurs minimale et maximale d'opérations d'E/S physiques par seconde (IOPS) par volume disque pour un pool de ressources. Vous pouvez utiliser ces paramètres pour contrôler les entrées/sorties physiques pour les threads utilisateur d'un pool de ressources donné. Par exemple, le service des ventes génère plusieurs rapports de fin de mois par lots de grande taille. Les requêtes de ces lots peuvent générer des E/S susceptibles de saturer le volume disque et d'affecter les performances d'autres charges de travail de priorité plus élevée dans la base de données. Pour isoler cette charge de travail, la valeur MIN_IOPS_PER_VOLUME est fixée à 20 et la valeur MAX_IOPS_PER_VOLUME est fixée à 100 pour la liste de ressources partagées du département des ventes. Ces paramètres contrôlent le niveau d'E/S qui peut être émis pour la charge de travail.

Listes de ressources partagées définis par le système et l'utilisateur

Le gouverneur de ressources prédéfinit deux pools de ressources, le pool interne et le pool par défaut. Vous pouvez créer des pools supplémentaires.

Pool interne

Le pool interne représente les ressources consommées par le serveur SQL Server lui-même. Ce pool ne contient toujours que le groupe interne et ne peut en aucun cas être modifié. La consommation des ressources par le pool interne n'est pas restreinte. Toutes les charges de travail du pool sont considérées comme critiques pour la fonction serveur. Par conséquent, Resource Governor permet au pool interne d'exercer une pression sur les autres pools, même si cela implique la violation des limites fixées pour les autres pools.

Pool par défaut

Le pool par défaut est le premier pool d'utilisateur prédéfini. Avant toute configuration, le pool par défaut contient seulement le groupe par défaut. Vous ne pouvez pas créer ou supprimer le pool par défaut, mais vous pouvez le modifier. Il peut contenir des groupes définis par l'utilisateur en plus du groupe par défaut. Depuis SQL Server 2016 (13.x), il existe une liste de ressources partagées par défaut pour les opérations courantes du serveur SQL et un pool de ressources externes par défaut pour les processus externes, tels que l'exécution de scripts R.

Pool externe

Les utilisateurs peuvent créer un pool externe pour définir des ressources pour les processus externes. Pour R Services, ce pool gouverne plus particulièrement rterm.exe, BxlServer.exepython.exe et les autres processus générés par ces derniers. Pour plus d'informations, consultez la CRÉER UNE LISTE DE RESSOURCES PARTAGÉES EXTERNES.

Pools de ressources définis par l'utilisateur

Les pools de ressources définis par l'utilisateur sont ceux que vous créez pour les charges de travail spécifiques dans votre environnement. Le gouverneur de ressources fournit des instructions DDL pour créer, modifier et supprimer des pools de ressources. Pour plus d'informations, consultez les Créer une liste de ressources partagées, Supprimer une liste de ressources partagées et Modifier les paramètres d'une liste de ressources partagées.

Affectation des ressources entre pools

Lors de la configuration du processeur ou de la mémoire, la somme des valeurs MIN pour l'ensemble des pools ne peut pas dépasser 100 pour cent des ressources de serveur. En outre, les valeurs MAX et CAP définies doivent être comprises entre MIN et 100 % inclus.
Si un pool est défini avec une valeur MIN différente de zéro, la valeur MAX effective des autres pools est réajustée. La valeur minimale de la valeur MAX d'un pool et de la somme des valeurs MIN des autres pools est soustraite de 100 %.

Le tableau suivant illustre quelques-uns des concepts précédents. Le tableau présente les paramètres définis pour le pool interne, le pool par défaut et deux pools définis par l'utilisateur.

Les formules suivantes calculent le pourcentage % MAX effectif et le pourcentage % partagé dans la table :

• Min(X,Y) représente la valeur plus petite de X et Y.

• Sum(X) représente la somme de la valeur X pour tous les pools.

• Total % partagé = 100 - sum(MIN %).

• % MAX effectif = min(X,Y).

• % partagé = % MAX effectif - % MIN.

Sur la base du tableau précédent donné en exemple, détaillons les ajustements qui sont effectués lors de la création d’un pool supplémentaire. Ce pool (Pool 3) a un paramètre % MIN égal à 5.

La partie partagée du pool est utilisée pour indiquer la destination des ressources disponibles si des ressources sont disponibles. Toutefois, lorsque les ressources sont consommées, elles sont acheminées vers le pool spécifié et ne sont pas partagées. Ce comportement peut améliorer l'utilisation des ressources en l'absence de demandes dans un pool donné. De plus, elle permet de libérer les ressources configurées du pool pour d'autres pools.

Dans certains cas extrêmes, les pools peuvent être configurés comme ci-dessous :

• Tous les pools sont définis avec des valeurs minimales qui représentent au total 100 pour cent des ressources de serveur. Dans ce cas, les valeurs maximales effectives sont égales aux valeurs minimales. Cela revient à diviser les ressources de serveur en portions qui ne se chevauchent pas, indépendamment des ressources consommées dans chaque pool.

• Tous les pools ont des valeurs minimales nulles. Tous les pools sont en concurrence pour les ressources disponibles et leurs tailles finales sont basées sur la consommation des ressources dans chaque pool. D'autres facteurs tels que les stratégies jouent un rôle dans la définition de la taille finale du pool.

Tâches du pool de ressources

Voir aussi

• gouverneur de ressources
• Groupe de charge de travail de Resource Governor
• Fonction classifieur de Resource Governor
• Configurer Resource Governor à l’aide d’un modèle
• Afficher les propriétés du gouverneur de ressources