Partager via

Propriétés du pool de threads

Analysis Services utilise le multithreading pour de nombreuses opérations, ce qui améliore les performances globales du serveur en exécutant plusieurs travaux en parallèle. Pour gérer plus efficacement les threads, Analysis Services utilise des pools de threads pour préallouer des threads et faciliter la disponibilité des threads pour le travail suivant.

Chaque instance d’Analysis Services gère son propre ensemble de pools de threads. Il existe des différences significatives dans la façon dont les instances tabulaires et multidimensionnelles utilisent des pools de threads. La différence la plus importante est que seules les solutions multidimensionnelles utilisent le pool de IOProcess threads. Par conséquent, la PerNumaNode propriété, décrite dans cette rubrique, n’est pas significative pour les instances tabulaires.

Cette rubrique contient les sections suivantes :

Remarque

Le déploiement tabulaire sur les systèmes NUMA est hors de portée pour cette rubrique. Bien que les solutions tabulaires puissent être déployées avec succès sur les systèmes NUMA, les caractéristiques de performances de la technologie de base de données en mémoire utilisée par les modèles tabulaires peuvent présenter des avantages limités sur une architecture hautement mise à l’échelle. Pour plus d’informations, consultez l’étude de cas Analysis Services : Utilisation de modèles tabulaires dans des solutions commerciales à grande échelle et dimensionnement matériel d’une solution tabulaire.

Gestion des threads dans Analysis Services

Analysis Services utilise le multithreading pour tirer parti des ressources processeur disponibles en augmentant le nombre de tâches en cours d’exécution en parallèle. Le moteur de stockage est multi-thread. Parmi les exemples de travaux multithread qui s’exécutent dans le moteur de stockage, citons le traitement d’objets en parallèle ou la gestion de requêtes discrètes envoyées au moteur de stockage ou le renvoi de valeurs de données demandées par une requête. Le moteur de formule, en raison de la nature sérielle des calculs qu’il évalue, est monothread. Chaque requête s’exécute principalement sur un thread unique, demandant et attendant souvent les données retournées par le moteur de stockage. Les threads de requête ont des exécutions plus longues et sont libérés uniquement une fois la requête entière terminée.

Par défaut, sur les versions SQL Server 2012 et ultérieures, Analysis Services utilise tous les processeurs logiques disponibles, jusqu’à 640 sur les systèmes exécutant des éditions supérieures de Windows et SQL Server. Au démarrage, le processus de msmdsrv.exe est affecté à un groupe de processeurs spécifique, mais au fil du temps, les threads peuvent être planifiés sur n’importe quel processeur logique, dans n’importe quel groupe de processeurs.

L’un des effets secondaires de l’utilisation d’un grand nombre de processeurs est que vous pouvez parfois rencontrer une dégradation des performances, car les charges de requête et de traitement sont réparties sur un grand nombre de processeurs et de contention pour les structures de données partagées augmentent. Cela peut se produire particulièrement sur les systèmes haut de gamme qui utilisent l’architecture NUMA, mais également sur les systèmes non NUMA exécutant plusieurs applications gourmandes en données sur le même matériel.

Pour résoudre ce problème, vous pouvez définir l’affinité entre les types d’opérations Analysis Services et un ensemble spécifique de processeurs logiques. La GroupAffinity propriété vous permet de créer des masques d’affinité personnalisés qui spécifient la ressource système à utiliser pour chacun des types de pool de threads gérés par Analysis Services.

L’affinité personnalisée peut être définie sur l’un des cinq pools de threads utilisés pour différentes charges de travail Analysis Services :

  • Parsing \ Short est un pool d'analyse pour des requêtes courtes. Les demandes qui s’intègrent dans un seul message réseau sont considérées comme courtes.

  • L’analyse \ Long est un pool d’analyse pour toutes les autres requêtes qui ne correspondent pas à un seul message réseau.

    Remarque

    Un thread d’un pool d’analyse peut être utilisé pour exécuter une requête. Les requêtes qui s’exécutent rapidement, telles qu’une demande de découverte rapide ou d’annulation, sont parfois exécutées immédiatement plutôt que mises en file d’attente dans le pool de threads de requête.

  • Query est le pool de threads qui exécute toutes les requêtes qui ne sont pas gérées par le pool de threads d’analyse. Les threads de ce pool de threads exécutent tous les types d’opérations, tels que Discovers, MDX, DAX, DMX et DDL.

  • IOProcess est utilisé pour les tâches d’E/S associées aux requêtes du moteur de stockage dans l'environnement du moteur multidimensionnel. Le travail effectué par ces threads est censé ne pas avoir de dépendances sur d’autres threads. Ces threads analysent généralement un segment unique d’une partition et effectuent un filtrage et une agrégation sur les données de segment. IOProcess Les threads sont particulièrement sensibles aux configurations matérielles NUMA. Par conséquent, ce pool de threads a la PerNumaNode propriété de configuration qui peut être utilisée pour régler les performances si nécessaire.

  • Process est destiné aux tâches du moteur de stockage à long terme, notamment les agrégations, l’indexation et les opérations de validation. Le mode de stockage ROLAP utilise également des threads du pool de threads de traitement.

Remarque

Bien que Msmdsrv.ini dispose de paramètres de pool de threads dans la section VertiPaq, VertiPaq\ThreadPool\GroupAffinity et ThreadPool\CPUs ne soient volontairement pas documentés. Ces propriétés sont actuellement inopérantes et sont réservées à une utilisation ultérieure.

Pour traiter les demandes, Analysis Services peut dépasser la limite maximale du pool de threads, en demandant des threads supplémentaires s’ils sont nécessaires pour effectuer le travail. Toutefois, lorsqu’un thread termine l’exécution de sa tâche, si le nombre actuel de threads est supérieur à la limite maximale, le thread est simplement terminé, plutôt que retourné au pool de threads.

Remarque

Le dépassement du nombre maximal de groupes de threads est une protection mise en œuvre uniquement lorsque certaines conditions de blocage se produisent. Pour empêcher la création de threads runaway au-delà du maximum, les threads sont créés progressivement (après un court délai) une fois la limite maximale atteinte. Le dépassement du nombre maximal de threads peut entraîner un ralentissement de l’exécution des tâches. Si les compteurs de performances indiquent que les nombres de threads sont régulièrement au-delà de la taille maximale du pool de threads, vous pouvez considérer qu’en tant qu’indicateur les tailles de pool de threads sont trop petites pour le degré d’accès concurrentiel demandé par le système.

Par défaut, la taille du pool de threads est déterminée par Analysis Services et est basée sur le nombre de cœurs. Vous pouvez observer les valeurs par défaut sélectionnées en examinant le fichier msmdsrv.log après le démarrage du serveur. En tant qu’exercice de réglage des performances, vous pouvez choisir d’augmenter la taille du pool de threads, ainsi que d’autres propriétés, pour améliorer les performances de requête ou de traitement.

Référence de propriété de pool de threads

Cette section décrit les propriétés du pool de threads trouvées dans le fichier msmdsrv.ini de chaque instance Analysis Services. Un sous-ensemble de ces propriétés apparaît également dans SQL Server Management Studio.

Les propriétés sont répertoriées par ordre alphabétique.

Nom Catégorie Descriptif Par défaut Instructions
IOProcess \ Concurrency double Valeur à virgule flottante double précision qui détermine l’algorithme permettant de définir le nombre cible de threads pouvant être mis en file d’attente simultanément. 2.0 Propriété avancée que vous ne devez pas modifier, sauf dans le cadre du support Microsoft.

L’accès concurrentiel est utilisé pour initialiser des pools de threads, qui sont implémentés à l’aide de ports d’achèvement d’E/S dans Windows. Pour plus d’informations, consultez les ports d’achèvement des E/S .

S’applique uniquement aux modèles multidimensionnels.
IOProcess \ GroupAffinity ficelle Tableau de valeurs hexadécimales qui correspondent aux groupes de processeurs sur le système, utilisé pour définir l’affinité des threads dans le pool de threads IOProcess sur des processeurs logiques dans chaque groupe de processeurs. Aucune Vous pouvez utiliser cette propriété pour créer des affinités personnalisées. La propriété est vide par défaut.

Pour plus d’informations, consultez Définir GroupAffinity pour associer les threads aux processeurs dans un groupe de processeurs.

S’applique uniquement aux modèles multidimensionnels.
IOProcess \ MaxThreads Int Entier 32 bits signé qui spécifie le nombre maximal de threads à inclure dans le pool de threads. 0 0 indique que le serveur détermine les valeurs par défaut. Par défaut, le serveur définit cette valeur sur 64 ou sur 10 fois le nombre de processeurs logiques, selon ce qui est supérieur. Par exemple, sur un système à 4 cœurs avec hyperthreading, le nombre maximal de threads du pool de threads est de 80 threads.

Si vous définissez cette valeur sur une valeur négative, le serveur multiple cette valeur par le nombre de processeurs logiques. Par exemple, lorsqu’il est défini sur -10 sur un serveur ayant 32 processeurs logiques, la valeur maximale est de 320 threads.

La valeur maximale est soumise aux processeurs disponibles par tout masque d’affinité personnalisé que vous avez défini précédemment. Par exemple, si vous définissez déjà l’affinité de pool de threads pour utiliser 8 processeurs sur 32 et que vous définissez maintenant MaxThreads sur -10, la limite supérieure du pool de threads est de 10 fois 8 ou 80 threads.

Les valeurs réelles utilisées pour cette propriété de pool de threads sont écrites dans le fichier journal msmdsrv lors du démarrage du service.

Pour plus d’informations sur le réglage des paramètres du pool de threads, consultez le Guide des opérations Analysis Services.

S’applique uniquement aux modèles multidimensionnels.
IOProcess \ MinThreads Int Un entier signé de 32 bits qui spécifie le nombre minimum de threads à préallouer pour le pool de threads. 0 0 indique que le serveur détermine les valeurs par défaut. Par défaut, le minimum est 1.

Si vous définissez cette valeur sur une valeur négative, le serveur multiple cette valeur par le nombre de processeurs logiques.

Les valeurs réelles utilisées pour cette propriété de pool de threads sont écrites dans le fichier journal msmdsrv lors du démarrage du service.

Pour plus d’informations sur le réglage des paramètres du pool de threads, consultez le Guide des opérations Analysis Services.

S’applique uniquement aux modèles multidimensionnels.
IOProcess \ PerNumaNode Int Entier 32 bits signé qui détermine le nombre de pools de threads créés pour le processus msmdsrv. -1 Les valeurs valides sont -1, 0, 1, 2

-1 = Le serveur sélectionne une stratégie de pool de threads d’E/S différente en fonction du nombre de nœuds NUMA. Sur les systèmes ayant moins de 4 nœuds NUMA, le comportement du serveur est identique à 0 (un pool de threads IOProcess est créé pour le système). Sur les systèmes ayant 4 nœuds ou plus, le comportement est identique à 1 (les pools de threads IOProcess sont créés pour chaque nœud).

0 = Désactive les pools de threads de nœud NUMA afin qu’il n’existe qu’un seul pool de threads IOProcess utilisé par le processus de msmdsrv.exe.

1 = Active un pool de threads IOProcess par nœud NUMA.

2 = Un pool de threads IOProcess par processeur logique. Les threads de chaque pool de threads sont affiniténés avec le nœud NUMA du processeur logique, avec le processeur idéal défini sur le processeur logique.

Pour plus d’informations, consultez Définir PerNumaNode pour affecter les threads d'entrée/sortie sur les processeurs dans un nœud NUMA.

S’applique uniquement aux modèles multidimensionnels.
IOProcess \ PriorityRatio Int Entier 32 bits signé qui peut être utilisé pour s’assurer que les threads de priorité inférieure sont parfois exécutés même lorsqu’une file d’attente de priorité supérieure n’est pas vide. 2 Propriété avancée que vous ne devez pas modifier, sauf dans le cadre du support Microsoft.

S’applique uniquement aux modèles multidimensionnels.
IOProcess \ StackSizeKB Int Entier 32 bits signé qui peut être utilisé pour ajuster l’allocation de mémoire pendant l’exécution du thread. 0 Propriété avancée que vous ne devez pas modifier, sauf dans le cadre du support Microsoft.

S’applique uniquement aux modèles multidimensionnels.
Analyse \ Long \ Concurrency double Valeur à virgule flottante en double précision utilisée pour définir l'algorithme qui fixe un objectif sur le nombre de threads pouvant être mis en file d'attente simultanément. 2.0 Propriété avancée que vous ne devez pas modifier, sauf dans le cadre du support Microsoft.

L’accès concurrentiel est utilisé pour initialiser des pools de threads, qui sont implémentés à l’aide de ports d’achèvement d’E/S dans Windows. Pour plus d’informations, consultez les ports d’achèvement des E/S .
Analyse \ Long \ GroupAffinity ficelle Tableau de valeurs hexadécimales qui correspondent aux groupes de processeurs sur le système, utilisé pour définir l’affinité entre les threads d’analyse et les processeurs logiques dans chaque groupe de processeurs. Aucune Vous pouvez utiliser cette propriété pour créer des affinités personnalisées. La propriété est vide par défaut.

Pour plus d'informations, consultez Définir l'affinité de groupe pour assigner une affinité des threads aux processeurs dans un groupe de processeurs.
Analyse \ Long \ NumThreads Int Propriété entière 32 bits signée qui définit le nombre de threads qui peuvent être créés pour les commandes longues. 0 0 indique que le serveur détermine les valeurs par défaut. Le comportement par défaut consiste à définir NumThreads une valeur absolue de 4 ou 2 fois le nombre de processeurs logiques, selon ce qui est supérieur.

Si vous définissez cette valeur sur une valeur négative, le serveur multiple cette valeur par le nombre de processeurs logiques. Par exemple, lorsqu’il est défini sur -10 sur un serveur ayant 32 processeurs logiques, la valeur maximale est de 320 threads.

La valeur maximale est soumise aux processeurs disponibles par tout masque d’affinité personnalisé que vous avez défini précédemment. Par exemple, si vous définissez déjà l’affinité de pool de threads pour utiliser 8 processeurs sur 32, et que vous définissez maintenant NumThreads sur -10, la limite supérieure du pool de threads est de 10 fois 8 ou 80 threads.

Les valeurs réelles utilisées pour cette propriété de pool de threads sont écrites dans le fichier journal msmdsrv lors du démarrage du service.
Analyse \ Long \ PriorityRatio Int Entier 32 bits signé qui peut être utilisé pour s’assurer que les threads de priorité inférieure sont parfois exécutés même lorsqu’une file d’attente de priorité supérieure n’est pas vide. 0 Propriété avancée que vous ne devez pas modifier, sauf dans le cadre du support Microsoft.
Analyse \ Long \ StackSizeKB Int Entier 32 bits signé qui peut être utilisé pour ajuster l’allocation de mémoire pendant l’exécution du thread. 0 Propriété avancée que vous ne devez pas modifier, sauf dans le cadre du support Microsoft.
Analyse \ Short \ Concurrency double Valeur à virgule flottante double précision qui détermine l’algorithme permettant de fixer un objectif sur le nombre de threads pouvant être mis en file d’attente simultanément. 2.0 Propriété avancée que vous ne devez pas modifier, sauf dans le cadre du support Microsoft.

La concurrence est utilisée pour initialiser des pools de threads, qui sont implémentés à l’aide de IO Completion Ports dans Windows. Pour plus d’informations, consultez les ports d’achèvement des E/S .
Analyse \ Short \ GroupAffinity ficelle Tableau de valeurs hexadécimales qui correspondent aux groupes de processeurs sur le système, utilisé pour définir l’affinité entre les threads d’analyse et les processeurs logiques dans chaque groupe de processeurs. Aucune Vous pouvez utiliser cette propriété pour créer des affinités personnalisées. La propriété est vide par défaut.

Pour plus d’informations, consultez Définir GroupAffinity afin d'attribuer les threads aux processeurs dans un groupe de processeurs.
Analyse \ Short \ NumThreads Int Propriété entière 32 bits signée qui définit le nombre de threads pouvant être créés pour les commandes courtes. 0 0 indique que le serveur détermine les valeurs par défaut. Le comportement par défaut consiste à définir NumThreads une valeur absolue de 4 ou 2 fois le nombre de processeurs logiques, selon ce qui est supérieur.

Si vous définissez cette valeur sur une valeur négative, le serveur multiple cette valeur par le nombre de processeurs logiques. Par exemple, lorsqu’il est défini sur -10 sur un serveur ayant 32 processeurs logiques, la valeur maximale est de 320 threads.

La valeur maximale est soumise aux processeurs disponibles par tout masque d’affinité personnalisé que vous avez défini précédemment. Par exemple, si vous définissez déjà l’affinité de pool de threads pour utiliser 8 processeurs sur 32, et que vous définissez maintenant NumThreads sur -10, la limite supérieure du pool de threads est de 10 fois 8 ou 80 threads.

Les valeurs réelles utilisées pour cette propriété de pool de threads sont écrites dans le fichier journal msmdsrv lors du démarrage du service.
Analyse \ Short \ PriorityRatio Int Entier 32 bits signé qui peut être utilisé pour s’assurer que les threads de priorité inférieure sont parfois exécutés même lorsqu’une file d’attente de priorité supérieure n’est pas vide. 0 Propriété avancée que vous ne devez pas modifier, sauf dans le cadre du support Microsoft.
Analyse \ Short \ StackSizeKB Int Entier 32 bits signé qui peut être utilisé pour ajuster l’allocation de mémoire pendant l’exécution du thread. Processeurs logiques 64 * Propriété avancée que vous ne devez pas modifier, sauf dans le cadre du support Microsoft.
Process \ Concurrency double Valeur à virgule flottante double précision qui détermine l’algorithme pour définir un objectif concernant le nombre de threads pouvant être mis en queue à la fois. 2.0 Propriété avancée que vous ne devez pas modifier, sauf dans le cadre du support Microsoft.

L’accès concurrentiel est utilisé pour initialiser des pools de threads, qui sont implémentés à l’aide de ports d’achèvement d’E/S dans Windows. Pour plus d’informations, consultez les ports d’achèvement des E/S .
Process \ GroupAffinity ficelle Tableau de valeurs hexadécimales qui correspondent aux groupes de processeurs sur le système, utilisé pour définir l’affinité entre les threads de traitement et les processeurs logiques de chaque groupe de processeurs. Aucune Vous pouvez utiliser cette propriété pour créer des affinités personnalisées. La propriété est vide par défaut.

Pour plus d'informations, consultez Définir GroupAffinity pour attribuer l'affinité des threads aux processeurs dans un groupe de processeurs.
Process \ MaxThreads Int Entier 32 bits signé qui spécifie le nombre maximal de threads à inclure dans le pool de threads. 0 0 indique que le serveur détermine les valeurs par défaut. Par défaut, le serveur définit cette valeur sur une valeur absolue de 64, ou le nombre de processeurs logiques, selon ce qui est supérieur. Par exemple, sur un système de 64 cœurs avec hyperthreading activé (ce qui entraîne 128 processeurs logiques), le nombre maximal de threads est de 128 threads.

Si vous définissez cette valeur sur une valeur négative, le serveur multiple cette valeur par le nombre de processeurs logiques. Par exemple, lorsqu’il est défini sur -10 sur un serveur ayant 32 processeurs logiques, la valeur maximale est de 320 threads.

La valeur maximale est soumise aux processeurs disponibles par tout masque d’affinité personnalisé que vous avez défini précédemment. Par exemple, si vous définissez déjà l’affinité de pool de threads pour utiliser 8 processeurs sur 32 et que vous définissez maintenant MaxThreads sur -10, la limite supérieure du pool de threads est de 10 fois 8 ou 80 threads.

Les valeurs réelles utilisées pour cette propriété de pool de threads sont écrites dans le fichier journal msmdsrv lors du démarrage du service.

Pour plus d’informations sur le réglage des paramètres du pool de threads, consultez le Guide des opérations Analysis Services.
Process \ MinThreads Int Un entier signé de 32 bits qui spécifie le nombre minimum de threads à préallouer pour le pool de threads. 0 0 indique que le serveur détermine les valeurs par défaut. Par défaut, le minimum est 1.

Si vous définissez cette valeur sur une valeur négative, le serveur multiple cette valeur par le nombre de processeurs logiques.

Les valeurs réelles utilisées pour cette propriété de pool de threads sont écrites dans le fichier journal msmdsrv lors du démarrage du service.

Pour plus d’informations sur le réglage des paramètres du pool de threads, consultez le Guide des opérations Analysis Services.
Process \ PriorityRatio Int Entier 32 bits signé qui peut être utilisé pour s’assurer que les threads de priorité inférieure sont parfois exécutés même lorsqu’une file d’attente de priorité supérieure n’est pas vide. 2 Propriété avancée que vous ne devez pas modifier, sauf dans le cadre du support Microsoft.
Process \ StackSizeKB Int Entier 32 bits signé qui peut être utilisé pour ajuster l’allocation de mémoire pendant l’exécution du thread. 0 Propriété avancée que vous ne devez pas modifier, sauf dans le cadre du support Microsoft.
Query \ Concurrency double Valeur à virgule flottante double précision qui détermine l’algorithme permettant de définir une cible sur le nombre de threads pouvant être mis en file d’attente à la fois. 2.0 Propriété avancée que vous ne devez pas modifier, sauf dans le cadre du support Microsoft.

L’accès concurrentiel est utilisé pour initialiser des pools de threads, qui sont implémentés à l’aide de ports d’achèvement d’E/S dans Windows. Pour plus d’informations, consultez les ports d’achèvement des E/S .
Query \ GroupAffinity ficelle Tableau de valeurs hexadécimales qui correspondent aux groupes de processeurs sur le système, utilisé pour définir l’affinité entre les threads de traitement et les processeurs logiques de chaque groupe de processeurs. Aucune Vous pouvez utiliser cette propriété pour créer des affinités personnalisées. La propriété est vide par défaut.

Pour plus d’informations, consultez Définir GroupAffinity pour attribuer des threads aux processeurs dans un groupe de processeurs.
Query \ MaxThreads Int Entier 32 bits signé qui spécifie le nombre maximal de threads à inclure dans le pool de threads. 0 0 indique que le serveur détermine les valeurs par défaut. Par défaut, le serveur définit cette valeur sur une valeur absolue de 10, ou 2 fois le nombre de processeurs logiques, selon la valeur la plus élevée. Par exemple, sur un système à 4 cœurs avec hyperthreading, le nombre maximal de threads est de 16.

Si vous définissez cette valeur sur une valeur négative, le serveur multiple cette valeur par le nombre de processeurs logiques. Par exemple, lorsqu’il est défini sur -10 sur un serveur ayant 32 processeurs logiques, la valeur maximale est de 320 threads.

La valeur maximale est soumise aux processeurs disponibles par tout masque d’affinité personnalisé que vous avez défini précédemment. Par exemple, si vous définissez déjà l’affinité de pool de threads pour utiliser 8 processeurs sur 32 et que vous définissez maintenant MaxThreads sur -10, la limite supérieure du pool de threads est de 10 fois 8 ou 80 threads.

Les valeurs réelles utilisées pour cette propriété de pool de threads sont écrites dans le fichier journal msmdsrv lors du démarrage du service.

Pour plus d’informations sur le réglage des paramètres du pool de threads, consultez le Guide des opérations Analysis Services.
Query \ MinThreads Int Entier 32 bits signé qui spécifie le nombre minimal de threads à préallouer pour le pool de threads. 0 0 indique que le serveur détermine les valeurs par défaut. Par défaut, le minimum est 1.

Si vous définissez cette valeur sur une valeur négative, le serveur multiple cette valeur par le nombre de processeurs logiques.

Les valeurs réelles utilisées pour cette propriété de pool de threads sont écrites dans le fichier journal msmdsrv lors du démarrage du service.

Pour plus d’informations sur le réglage des paramètres du pool de threads, consultez le Guide des opérations Analysis Services.
Query \ PriorityRatio Int Entier 32 bits signé qui peut être utilisé pour s’assurer que les threads de priorité inférieure sont parfois exécutés même lorsqu’une file d’attente de priorité supérieure n’est pas vide. 2 Propriété avancée que vous ne devez pas modifier, sauf dans le cadre du support Microsoft.
Query \ StackSizeKB Int Entier 32 bits signé qui peut être utilisé pour ajuster l’allocation de mémoire pendant l’exécution du thread. 0 Propriété avancée que vous ne devez pas modifier, sauf dans le cadre du support Microsoft.

Définir GroupAffinity pour associer les threads aux processeurs d'un groupe de processeurs

GroupAffinity est fourni à des fins de réglage avancées. Vous pouvez utiliser la propriété pour définir l’affinité GroupAffinity entre les pools de threads Analysis Services et des processeurs spécifiques. Toutefois, pour la plupart des installations, Analysis Services fonctionne le mieux lorsqu’il peut utiliser tous les processeurs logiques disponibles. En conséquence, l’affinité de groupe n’est pas spécifiée par défaut.

Si les tests de performances indiquent un besoin d’optimisation du processeur, vous pouvez envisager une approche de niveau supérieur, comme l’utilisation de Windows Server Resource Manager pour définir l’affinité entre les processeurs logiques et un processus serveur. Une telle approche peut être plus simple à implémenter et à gérer que de définir des affinités personnalisées pour des pools de threads individuels.

Si cette approche est insuffisante, vous pouvez obtenir une plus grande précision en définissant des affinités personnalisées pour les pools de threads. La personnalisation des paramètres d’affinité est plus susceptible d’être recommandée sur les systèmes multicœurs volumineux (NUMA ou non NUMA) qui subissent une dégradation des performances en raison d’une dégradation des performances en raison de pools de threads répartis sur un trop large éventail de processeurs. Bien que vous puissiez définir GroupAffinity sur les systèmes ayant moins de 64 processeurs logiques, l’avantage est négligeable et peut même dégrader les performances.

Remarque

GroupAffinity est limité par les éditions qui limitent le nombre de cœurs utilisés par Analysis Services. Au démarrage, Analysis Services utilise des informations d’édition et les GroupAffinity propriétés pour calculer des masques d’affinité pour chacun des 5 pools de threads gérés par Analysis Services. L’édition standard peut utiliser un maximum de 16 cœurs. Si vous installez Analysis Services édition standard sur un système multicœur volumineux qui a plus de 16 cœurs, Analysis Services n’utilisera que 16 d’entre eux. Si vous mettez à niveau une instance Entreprise d’une version antérieure, vous serez limité à 20 cœurs. Pour plus d’informations sur les éditions et les licences, consultez La vue d’ensemble des licences SQL Server 2012.

Syntaxe

La valeur est hexadécimale pour chaque groupe de processeurs, avec l’hexadécimal représentant les processeurs logiques que Analysis Services tente d’utiliser en premier lors de l’allocation de threads pour un pool de threads donné.

Masque de bits pour les processeurs logiques

Vous pouvez avoir jusqu’à 64 processeurs logiques au sein d’un seul groupe de processeurs. Le masque de bits est 1 (ou 0) pour chaque processeur logique du groupe utilisé (ou non utilisé) par un pool de threads. Une fois que vous avez calculé le masque de bits, vous calculez la valeur hexadécimale comme valeur pour GroupAffinity.

Plusieurs groupes de processeurs

Les groupes de processeurs sont déterminés au démarrage du système. GroupAffinity accepte les valeurs hexadécimales pour chaque groupe de processeurs dans une liste délimitée par des virgules. Compte tenu de plusieurs groupes de processeurs (jusqu’à 10 sur les systèmes supérieurs), vous pouvez contourner les groupes individuels en spécifiant 0x0. Par exemple, sur un système avec quatre groupes de processeurs (0, 1, 2, 3), vous pouvez exclure les groupes 0 et 2 en entrant 0x0 pour les premières et troisième valeurs.

<GroupAffinity>0x0, 0xFF, 0x0, 0xFF</GroupAffinity>

Étapes de calcul du masque d’affinité du processeur

Vous pouvez définir GroupAffinity dans msmdsrv.ini ou dans les pages de propriétés du serveur dans SQL Server Management Studio.

  1. Déterminer le nombre de processeurs et de groupes de processeurs

    Vous pouvez télécharger l’utilitaire Coreinfo à partir de winsysinternals.

    Exécutez coreinfo pour obtenir ces informations de la section Processeur logique vers Carte de groupe. Une ligne distincte est générée pour chaque processeur logique.

  2. Séquencez les processeurs, de droite à gauche : 7654 3210

    L’exemple montre seulement 8 processeurs (0 à 7), mais un groupe de processeurs peut avoir un maximum de 64 processeurs logiques, et il peut y avoir jusqu’à 10 groupes de processeurs dans un serveur Windows de classe entreprise.

  3. Calculer le masque de bits pour les groupes de processeurs que vous souhaitez utiliser

    7654 3210

    Remplacez le nombre par un nombre 0 ou 1, selon que vous souhaitez exclure ou inclure le processeur logique. Sur un système disposant de huit processeurs, votre calcul peut ressembler à ceci si vous souhaitez utiliser des processeurs 7, 6, 5, 4 et 1 pour Analysis Services :

    1111 0010

  4. Convertir le nombre binaire en valeur hexadécimal

    À l’aide d’une calculatrice ou d’un outil de conversion, convertissez le nombre binaire en son équivalent hexadécimal. Dans notre exemple, 1111 0010 convertit en 0xF2.

  5. Entrez la valeur hexadécimal dans la propriété GroupAffinity

    Dans msmdsrv.ini ou dans la page de propriétés du serveur dans Management Studio, définissez GroupAffinity la valeur calculée à l’étape 4.

Important

Le paramètre GroupAffinity est une tâche manuelle englobant plusieurs étapes. Lors du calcul GroupAffinity, vérifiez soigneusement vos calculs. Bien que Analysis Services retourne une erreur si l’intégralité du masque n’est pas valide, une combinaison de paramètres valides et non valides entraîne l’ignorance de la propriété par Analysis Services. Par exemple, si le masque de bits inclut des valeurs supplémentaires, Analysis Services ignore le paramètre, à l’aide de tous les processeurs sur le système. Il n’y a pas d’erreur ou d’avertissement pour vous avertir lorsque cette action se produit, mais vous pouvez vérifier le fichier msmdsrv.log pour savoir comment les affinités sont réellement définies.

Définir PerNumaNode pour attribuer les threads d'E/S aux processeurs dans un nœud NUMA.

Pour les instances Analysis Services multidimensionnelles, vous pouvez définir PerNumaNode sur le pool de threads pour optimiser davantage la IOProcess planification et l’exécution des threads. Alors que GroupAffinity identifie l’ensemble de processeurs logiques à utiliser pour un pool de threads donné, PerNumaNode va un pas plus loin en spécifiant s’il faut créer plusieurs pools de threads, avec une affinité supplémentaire à un sous-ensemble des processeurs logiques autorisés.

Remarque

Sur Windows Server 2012, utilisez le Gestionnaire de tâches pour afficher le nombre de nœuds NUMA sur l’ordinateur. Dans le Gestionnaire des tâches, sous l’onglet Performances, sélectionnez PROCESSEUR , puis cliquez avec le bouton droit sur la zone de graphique pour afficher les nœuds NUMA. Vous pouvez également télécharger l’utilitaire Coreinfo à partir de Windows Sysinternals et exécuter coreinfo -n pour retourner des nœuds NUMA et des processeurs logiques dans chaque nœud.

Les valeurs valides sont PerNumaNode -1, 0, 1, 2, comme décrit dans la section Référence des propriétés du pool de threads de cette rubrique.

Sur les systèmes disposant de nœuds NUMA, nous vous recommandons d’utiliser le paramètre par défaut de PerNumaNode=-1, ce qui permet à Analysis Services d’ajuster le nombre de pools de threads et leur affinité de thread en fonction du nombre de nœuds. Si le système a moins de 4 nœuds, Analysis Services implémente les comportements décrits par PerNumaNode=0, tandis que PerNumaNode=1 est utilisé sur les systèmes ayant 4 nœuds ou plus.

Choix d’une valeur

Vous pouvez également remplacer la valeur par défaut pour utiliser une autre valeur valide.

Définition de PerNumaNode=0

Les nœuds NUMA sont ignorés. Il n’y aura qu’un seul pool de threads IOProcess, et tous les threads de ce pool de threads seront affiniténés avec tous les processeurs logiques. Par défaut (où PerNumaNode=-1), il s’agit du paramètre opérationnel si l’ordinateur a moins de 4 nœuds NUMA.

Numa, correspondance entre processeur et pool de threads

Définition de PerNumaNode=1

Les pools de threads IOProcess sont créés pour chaque nœud NUMA. Le fait d’avoir des pools de threads distincts améliore l’accès coordonné aux ressources locales, telles que le cache local sur un nœud NUMA.

Correspondance entre le Numa, le processeur et le pool de threads

Définition de PerNumaNode=2

Ce paramètre concerne les systèmes très haut de gamme exécutant des charges de travail Analysis Services intensives. Cette propriété définit l’affinité du pool de threads IOProcess au niveau le plus granulaire, en créant et en affinitéant des pools de threads distincts au niveau du processeur logique.

Dans l’exemple suivant, sur un système ayant 4 nœuds NUMA et 32 processeurs logiques, la valeur PerNumaNode 2 entraînerait 32 pools de threads IOProcess. Les threads des 8 premiers pools de threads seraient affiniténés avec tous les processeurs logiques dans le nœud NUMA 0, mais avec le processeur idéal défini sur 0, 1, 2, jusqu’à 7. Les 8 pools de threads suivants seront affinitisés à tous les processeurs logiques du nœud NUMA 1, avec le processeur idéal défini comme étant 8, 9, 10, jusqu’à 15.

Correspondance entre Numa, processeur et pool de threads

À ce niveau d’affinité, le planificateur tente toujours d’utiliser le processeur logique idéal en premier, dans le nœud NUMA préféré. Si le processeur logique n’est pas disponible, le planificateur choisit un autre processeur au sein du même nœud ou dans le même groupe de processeurs si aucun autre thread n’est disponible. Pour plus d’informations et d’exemples, consultez les paramètres de configuration d’Analysis Services 2012 (blog Wordpress).

Distribution de travail entre les threads IOProcess

Lorsque vous envisagez de définir la PerNumaNode propriété, savoir comment IOProcess les threads sont utilisés peut vous aider à prendre une décision plus éclairée.

Notez que IOProcess est utilisé pour les travaux d’E/S associés aux requêtes du moteur de stockage et au moteur multidimensionnel.

Lorsqu’un segment est analysé, le moteur identifie la partition à laquelle appartient le segment et tente de mettre en file d’attente la tâche de segment dans le pool de threads utilisé par la partition. En règle générale, tous les segments appartenant à une partition mettent en file d’attente leurs tâches dans le même pool de threads. Sur les systèmes NUMA, ce comportement est particulièrement avantageux, car toutes les analyses d’une partition utilisent la mémoire dans le cache du système de fichiers alloué localement à ce nœud NUMA.

Les scénarios suivants suggèrent des ajustements qui peuvent parfois améliorer les performances des requêtes sur les systèmes NUMA :

  • Pour les groupes de mesures sous-partitionnés (par exemple, ayant une partition unique), augmentez le nombre de partitions. L’utilisation d’une seule partition entraîne la mise en file d’attente des tâches du moteur vers un pool de threads (pool de threads 0). L’ajout de partitions supplémentaires permet au moteur d’utiliser des pools de threads supplémentaires.

    Sinon, si vous ne pouvez pas créer de partitions supplémentaires, essayez de définir PerNumaNode=0 comme moyen d’augmenter le nombre de threads disponibles pour le pool de threads 0.

  • Pour les bases de données dans lesquelles les analyses de segment sont réparties uniformément entre plusieurs partitions, la définition PerNumaNode sur 1 ou 2 peut améliorer les performances des requêtes, car elle augmente le nombre global de pools de IOProcess threads utilisés par le système.

  • Pour les solutions qui ont plusieurs partitions, mais qu’une seule est fortement analysée, essayez de définir PerNumaNode=0 pour voir si elle améliore les performances.

Bien que les analyses de partition et de dimension utilisent le IOProcess pool de threads, les analyses de dimension utilisent uniquement le pool de threads 0. Cela peut entraîner une charge légèrement inégale sur ce pool de threads, mais le déséquilibre doit être temporaire, car les analyses de dimension ont tendance à être très rapides et peu fréquentes.

Remarque

Lors de la modification d’une propriété de serveur, n’oubliez pas que l’option de configuration s’applique à toutes les bases de données exécutées sur l’instance actuelle. Choisissez les paramètres qui bénéficient des bases de données les plus importantes ou le plus grand nombre de bases de données. Vous ne pouvez pas définir l’affinité du processeur au niveau de la base de données, ni définir l’affinité entre des partitions individuelles et des processeurs spécifiques.

Pour plus d’informations sur l’architecture des travaux, consultez la section 2.2 dans le Guide des performances de SQL Server 2008 Analysis Services.

Comme expliqué dans la section 2.4 du Guide des opérations Analysis Services, si vous augmentez le pool de threads de traitement, vous devez vous assurer que les paramètres CoordinatorExecutionMode ainsi que les paramètres CoordinatorQueryMaxThreads ont des valeurs qui vous permettent de tirer pleinement profit de la taille accrue du pool de threads.

Analysis Services utilise un thread coordinateur pour collecter les données nécessaires pour effectuer un traitement ou une demande de requête. Le coordinateur met d’abord en file d’attente un travail pour chaque partition qui doit être tactile. Chacun de ces travaux continue ensuite de mettre en file d’attente davantage de travaux, en fonction du nombre total de segments qui doivent être analysés dans la partition.

La valeur par défaut est CoordinatorExecutionMode -4, ce qui signifie une limite de 4 travaux en parallèle par cœur, ce qui limite le nombre total de travaux coordinateurs qui peuvent être exécutés en parallèle par une demande de sous-cube dans le moteur de stockage.

La valeur par défaut de CoordinatorQueryMaxThreads 16, qui limite le nombre de travaux de segment qui peuvent être exécutés en parallèle pour chaque partition.

Déterminer les paramètres actuels du pool de threads

Au démarrage de chaque service, Analysis Services génère les paramètres actuels du pool de threads dans le fichier msmdsrv.log, y compris les threads minimum et maximal, le masque d’affinité du processeur et la concurrence.

L’exemple suivant est un extrait du fichier journal, montrant les paramètres par défaut du pool de threads de requête (MinThread=0, MaxThread=0, Concurrency=2), sur un système 4 cœurs avec hyperthreading activé. Le masque d’affinité est 0xFF, indiquant 8 processeurs logiques. Notez que les zéros non significatifs sont ajoutés au masque. Vous pouvez ignorer les zéros non significatifs.

"10/28/2013 9:20:52 AM) Message: The Query thread pool now has 1 minimum threads, 16 maximum threads, and a concurrency of 16. Its thread pool affinity mask is 0x00000000000000ff. (Source: \\?\C:\Program Files\Microsoft SQL Server\MSAS11.MSSQLSERVER\OLAP\Log\msmdsrv.log, Type: 1, Category: 289, Event ID: 0x4121000A)"

Rappelez-vous que l’algorithme permettant de définir MinThread et MaxThread incorpore la configuration du système, en particulier le nombre de processeurs. Le billet de blog suivant fournit des insights sur la façon dont les valeurs sont calculées : paramètres de configuration Analysis Services 2012 (blog Wordpress). Notez que ces paramètres et comportements sont soumis à un ajustement dans les versions ultérieures.

La liste suivante présente des exemples d’autres paramètres de masque d’affinité, pour différentes combinaisons de processeurs :

  • L’affinité pour les processeurs 3-2-1-0 sur un système de 8 cœurs entraîne ce masque de bits : 00001111 et une valeur hexadécimale : 0xF

  • L’affinité pour les processeurs 7-6-5-4 sur un système de 8 cœurs entraîne ce masque de bits : 11110000 et une valeur hexadécimale : 0xF0

  • L’affinité pour les processeurs 5-4-3-2 sur un système de 8 cœurs entraîne ce masque de bits : 00111100 et une valeur hexadécimale : 0x3C

  • L’affinité pour les processeurs 7-6-1-0 sur un système de 8 cœurs entraîne ce masque de bits : 11000011 et une valeur hexadécimale : 0xC3

Rappelez-vous que sur les systèmes ayant plusieurs groupes de processeurs, un masque d’affinité distinct est généré pour chaque groupe, dans une liste séparée par des virgules.

À propos de MSMDSRV. INI

Le fichier msmdsrv.ini contient des paramètres de configuration pour une instance Analysis Services, affectant toutes les bases de données exécutées sur cette instance. Vous ne pouvez pas utiliser les propriétés de configuration du serveur pour optimiser les performances d’une seule base de données à l’exclusion de tous les autres. Toutefois, vous pouvez installer plusieurs instances d’Analysis Services et configurer chaque instance pour utiliser des propriétés qui bénéficient aux bases de données partageant des caractéristiques ou des charges de travail similaires.

Toutes les propriétés de configuration du serveur sont incluses dans le fichier msmdsrv.ini. Les sous-ensembles des propriétés plus susceptibles d’être modifiés apparaissent également dans les outils d’administration, tels que SSMS.

Le contenu de msmdsrv.ini est identique pour les instances tabulaires et multidimensionnelles d’Analysis Services. Toutefois, certains paramètres s’appliquent à un seul mode. Les différences de comportement en fonction du mode serveur sont notées dans la documentation de référence sur les propriétés.

Remarque

Pour obtenir des instructions sur la définition des propriétés, consultez Configurer les propriétés du serveur dans Analysis Services.

Voir aussi

À propos des processus et threadsMultiples processeursGroupes de processeursModifications du pool de threads des Analysis Services dans SQL Server 2012Paramètres de configuration Analysis Services 2012 (blog WordPress)Prise en charge des systèmes qui ont plus de 64 processeursGuide des opérations SQL Server 2008 R2 Analysis Services

  • Last updated on