Entrelacement de requêtes

Article
12/23/2023

S’applique à : SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

L’entrelacement de requêtes est une configuration système en mode tabulaire qui peut améliorer les performances des requêtes dans les scénarios de haute concurrence. Par défaut, le moteur tabulaire Analysis Services fonctionne en mode premier entré, premier sorti (FIFO) en ce qui concerne le processeur. Avec FIFO, par exemple, si une requête de moteur de stockage coûteuse et éventuellement lente est reçue, puis suivie de deux requêtes par ailleurs rapides, les requêtes rapides peuvent potentiellement être bloquées en attendant la fin de la requête coûteuse. Ce comportement est illustré dans le diagramme suivant, qui montre Q1, Q2 et Q3 comme requêtes respectives, leur durée et le temps processeur.

Premier entrant, premier sorti

L’entrelacement des requêtes avec un biais de requête court permet aux requêtes simultanées de partager des ressources processeur, ce qui signifie que les requêtes rapides ne sont pas bloquées derrière les requêtes lentes. Le temps nécessaire à l’exécution des trois requêtes est toujours à peu près le même, mais dans notre exemple Q2 et Q3 ne sont pas bloqués jusqu’à la fin. Le biais de requête courte signifie que les requêtes rapides, définies par la quantité de processeur que chaque requête a déjà consommée à un moment donné, peuvent recevoir une proportion plus élevée de ressources que les requêtes de longue durée. Dans le diagramme suivant, les requêtes Q2 et Q3 sont considérées comme rapides et allouées plus de processeur que T1.

Biais de requête court

L’entrelacement des requêtes est destiné à avoir peu ou pas d’impact sur les performances sur les requêtes qui s’exécutent de manière isolée . Une requête unique peut toujours consommer autant de processeur qu’avec le modèle FIFO.

Considérations importantes

Avant de déterminer si l’entrelacement des requêtes est adapté à votre scénario, gardez à l’esprit les points suivants :

L’entrelacement des requêtes s’applique uniquement aux modèles d’importation. Elle n’affecte pas les modèles DirectQuery.
L’entrelacement de requêtes prend uniquement en compte le processeur consommé par les requêtes du moteur de stockage VertiPaq. Elle ne s’applique pas aux opérations du moteur de formule.
Une requête DAX unique peut entraîner plusieurs requêtes du moteur de stockage VertiPaq. Une requête DAX est considérée comme rapide ou lente en fonction de l’UC consommée par ses requêtes de moteur de stockage. La requête DAX est l’unité de mesure.
Les opérations d’actualisation sont par défaut protégées contre l’entrelacement des requêtes. Les opérations d’actualisation de longue durée sont classées différemment des requêtes longues.

Configurer

Pour configurer l’entrelacement des requêtes, définissez la propriété Threadpool\SchedulingBehavior . Cette propriété peut être spécifiée avec les valeurs suivantes :

Valeur	Description
-1	Automatique. Le moteur choisit le type de file d’attente.
0 (valeur par défaut pour SSAS 2019)	Premier entré, premier sorti (FIFO).
1	Biais de requête court. Le moteur limite progressivement les requêtes de longue durée en cas de pression en faveur des requêtes rapides.
3 (par défaut pour Azure AS, Power BI, SSAS 2022 et versions ultérieures)	Biais de requête court avec annulation rapide. Améliore les temps de réponse aux requêtes utilisateur dans les scénarios de haute concurrence. S’applique uniquement à Azure AS, Power BI, SSAS 2022 et versions ultérieures.

À ce stade, la propriété SchedulingBehavior peut être définie uniquement à l’aide de XMLA. Dans SQL Server Management Studio, l’extrait de code XMLA suivant définit la propriété SchedulingBehavior sur 1, bref biais de requête.

<Alter AllowCreate="true" ObjectExpansion="ObjectProperties" xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
  <Object />
  <ObjectDefinition>
    <Server xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ddl2="http://schemas.microsoft.com/analysisservices/2003/engine/2" xmlns:ddl2_2="http://schemas.microsoft.com/analysisservices/2003/engine/2/2" xmlns:ddl100_100="http://schemas.microsoft.com/analysisservices/2008/engine/100/100" xmlns:ddl200="http://schemas.microsoft.com/analysisservices/2010/engine/200" xmlns:ddl200_200="http://schemas.microsoft.com/analysisservices/2010/engine/200/200" xmlns:ddl300="http://schemas.microsoft.com/analysisservices/2011/engine/300" xmlns:ddl300_300="http://schemas.microsoft.com/analysisservices/2011/engine/300/300" xmlns:ddl400="http://schemas.microsoft.com/analysisservices/2012/engine/400" xmlns:ddl400_400="http://schemas.microsoft.com/analysisservices/2012/engine/400/400" xmlns:ddl500="http://schemas.microsoft.com/analysisservices/2013/engine/500" xmlns:ddl500_500="http://schemas.microsoft.com/analysisservices/2013/engine/500/500">
      <ID>myserver</ID>
      <Name>myserver</Name>
      <ServerProperties>
        <ServerProperty>
          <Name>ThreadPool\SchedulingBehavior</Name>
          <Value>1</Value>
        </ServerProperty>
      </ServerProperties>
    </Server>
  </ObjectDefinition>
</Alter>

Important

Un redémarrage du serveur instance est nécessaire. Dans Azure Analysis Services, vous devez suspendre, puis reprendre le serveur, en redémarrant efficacement.

Propriétés supplémentaires

Dans la plupart des cas, SchedulingBehavior est la seule propriété que vous devez définir. Les propriétés supplémentaires suivantes ont des valeurs par défaut qui doivent fonctionner dans la plupart des scénarios avec un biais de requête court, mais elles peuvent être modifiées si nécessaire. Les propriétés suivantes n’ont aucun effet , sauf si l’entrelacement des requêtes est activé en définissant la propriété SchedulingBehavior.

ReservedComputeForFastQueries : définit le nombre de cœurs logiques réservés pour les requêtes rapides . Toutes les requêtes sont considérées comme rapides jusqu’à ce qu’elles se décomposent, car elles ont utilisé une certaine quantité de processeur. ReservedComputeForFastQueries est un entier compris entre 0 et 100. La valeur par défaut est 75.

L’unité de mesure de ReservedComputeForFastQueries est le pourcentage de cœurs. Par exemple, une valeur de 80 sur un serveur avec 20 cœurs tente de réserver 16 cœurs pour des requêtes rapides (alors qu’aucune opération d’actualisation n’est effectuée). ReservedComputeForFastQueries arrondit au nombre entier de cœurs le plus proche. Il est recommandé de ne pas définir cette valeur de propriété en dessous de 50. En effet, les requêtes rapides peuvent être privées et sont contraires à la conception globale de la fonctionnalité.

DecayIntervalCPUTime : entier représentant le temps processeur en millisecondes qu’une requête passe avant qu’elle ne se décompose. Si le système est soumis à la pression du processeur, les requêtes dégradées sont limitées aux cœurs restants qui ne sont pas réservés aux requêtes rapides. La valeur par défaut est 60 000. Cela représente 1 minute de temps processeur, pas de temps de calendrier écoulé.

ReservedComputeForProcessing : définit le nombre de cœurs logiques réservés pour chaque opération de traitement (actualisation des données). La valeur de la propriété est un entier compris entre 0 et 100, avec une valeur par défaut de 75 exprimée. La valeur représente un pourcentage des cœurs déterminés par la propriété ReservedComputeForFastQueries. La valeur 0 (zéro) signifie que les opérations de traitement sont soumises à la même logique d’entrelacement des requêtes que les requêtes, et peuvent donc être désintégrées.

Bien qu’aucune opération de traitement ne soit effectuée, ReservedComputeForProcessing n’a aucun effet. Par exemple, avec la valeur 80, ReservedComputeForFastQueries sur un serveur avec 20 cœurs réserve 16 cœurs pour les requêtes rapides. Avec une valeur de 75, ReservedComputeForProcessing réserve alors 12 des 16 cœurs pour les opérations d’actualisation, laissant 4 pour les requêtes rapides pendant que les opérations de traitement sont en cours d’exécution et consomment du processeur. Comme décrit dans la section Requêtes désintégrées ci-dessous, les 4 cœurs restants (non réservés aux requêtes rapides ou aux opérations de traitement) seront toujours utilisés pour les requêtes rapides et le traitement en cas d’inactivité.

Ces propriétés supplémentaires se trouvent sous le nœud Propriétés ResourceGovernance . Dans SQL Server Management Studio, l’exemple d’extrait de code XMLA suivant affecte à la propriété DecayIntervalCPUTime une valeur inférieure à la valeur par défaut :

<Alter AllowCreate="true" ObjectExpansion="ObjectProperties" xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
  <Object />
  <ObjectDefinition>
    <Server xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ddl2="http://schemas.microsoft.com/analysisservices/2003/engine/2" xmlns:ddl2_2="http://schemas.microsoft.com/analysisservices/2003/engine/2/2" xmlns:ddl100_100="http://schemas.microsoft.com/analysisservices/2008/engine/100/100" xmlns:ddl200="http://schemas.microsoft.com/analysisservices/2010/engine/200" xmlns:ddl200_200="http://schemas.microsoft.com/analysisservices/2010/engine/200/200" xmlns:ddl300="http://schemas.microsoft.com/analysisservices/2011/engine/300" xmlns:ddl300_300="http://schemas.microsoft.com/analysisservices/2011/engine/300/300" xmlns:ddl400="http://schemas.microsoft.com/analysisservices/2012/engine/400" xmlns:ddl400_400="http://schemas.microsoft.com/analysisservices/2012/engine/400/400" xmlns:ddl500="http://schemas.microsoft.com/analysisservices/2013/engine/500" xmlns:ddl500_500="http://schemas.microsoft.com/analysisservices/2013/engine/500/500">
      <ID>myserver</ID>
      <Name>myserver</Name>
      <ServerProperties>
        <ServerProperty>
          <Name>ResourceGovernance\DecayIntervalCPUTime</Name>
          <Value>15000</Value>
        </ServerProperty>
      </ServerProperties>
    </Server>
  </ObjectDefinition>
</Alter>

Requêtes désintégrées

Les contraintes décrites dans cette section s’appliquent uniquement si le système est soumis à la pression du processeur. Par exemple, une requête unique, si elle est la seule en cours d’exécution dans le système à un moment donné, peut consommer tous les cœurs disponibles, qu’elle ait ou non été décomposée.

Chaque requête peut nécessiter de nombreux travaux de moteur de stockage. Lorsqu’un cœur du pool pour les requêtes désintégrées devient disponible, le planificateur case activée la requête en cours d’exécution la plus ancienne en fonction du temps de calendrier écoulé pour voir s’il a déjà utilisé son droit mce (Maximum Core Entitlement). Si non, son travail suivant est exécuté. Si oui, la requête la plus ancienne suivante est évaluée. La requête MCE est déterminée par le nombre d’intervalles de désintégration qu’elle a déjà utilisés. Pour chaque intervalle de désintégration utilisé, l’environnement MCE est réduit en fonction de l’algorithme indiqué dans le tableau ci-dessous. Cela se poursuit jusqu’à ce que la requête se termine, expire ou que l’environnement MCE soit réduit à un seul cœur.

Dans l’exemple suivant, le système a 32 cœurs et le processeur du système est sous pression.

ReservedComputeForFastQueries est de 60 (60 %).

20 cœurs (19,2 arrondis vers le haut) sont réservés aux requêtes rapides.
Les 12 cœurs restants sont alloués pour les requêtes décomposées.

DecayIntervalCPUTime est de 60 000 (1 minute de temps processeur).

Le cycle de vie d’une requête peut être le suivant, tant qu’elle n’expire pas ou ne se termine pas :

Étape	Statut	Exécution/planification	MCE
0	Rapide	L’environnement MCE est de 20 cœurs (réservé aux requêtes rapides). La requête est exécutée de manière FIFO par rapport à d’autres requêtes rapides sur les 20 cœurs réservés. L’intervalle de décroissance de 1 minute de temps processeur est utilisé.	20 = MIN(32/2˄0, 20)
1	Pourri	Le MCE est défini sur 12 cœurs (12 cœurs restants non réservés aux requêtes rapides). Les travaux sont exécutés en fonction de la disponibilité jusqu’à MCE. L’intervalle de désintégration de 1 minute du temps processeur est utilisé.	12 = MIN(32/2˄1, 12)
2	Pourri	L’environnement MCE est défini sur 8 cœurs (quart de 32 cœurs totaux). Les travaux sont exécutés en fonction de la disponibilité jusqu’à MCE. L’intervalle de désintégration de 1 minute du temps processeur est utilisé.	8 = MIN(32/2˄2, 12)
3	Pourri	McE est défini sur 4 cœurs. Les travaux sont exécutés en fonction de la disponibilité jusqu’à MCE. L’intervalle de désintégration de 1 minute du temps processeur est utilisé.	4 = MIN(32/2˄3, 12)
4	Pourri	L’environnement MCE est défini sur 2 cœurs. Les travaux sont exécutés en fonction de la disponibilité jusqu’à MCE. L’intervalle de désintégration de 1 minute du temps processeur est utilisé.	2 = MIN(32/2˄4, 12)
5	Pourri	L’environnement MCE est défini sur 1 cœur. Les travaux sont exécutés en fonction de la disponibilité jusqu’à MCE. L’intervalle de désintégration ne s’applique pas, car la requête a atteint le bas. Aucune autre dégradation puisque le minimum de 1 cœur est atteint.	1 = MIN(32/2˄5, 12)

Si le système est soumis à la pression du processeur, chaque requête ne reçoit pas plus de cœurs que son MCE. Si tous les cœurs sont actuellement utilisés par les requêtes au sein de leurs MCE respectifs, d’autres requêtes attendent que les cœurs soient disponibles. À mesure que les cœurs deviennent disponibles, la requête la plus ancienne en fonction de son temps de calendrier écoulé est récupérée. Le MCE est un capuchon sous pression ; il ne garantit pas ce nombre de cœurs à tout moment.

Voir aussi

Propriétés de serveur dans Analysis Services