L'hyperthreading fait référence à la mise en œuvre simultanée de multithreading (SMT), qui améliore la parallélisation des calculs réalisés sur les processeurs x86. La colocation sécurisée est disponible sur les processeurs Intel et AMD.

L'hyperthreading entraîne des CPU logiques qui apparaissent sous forme de CPU physiques au système d'exploitation. SQL Server voit ensuite ces CPU supplémentaires et les utilise comme s'il y avait plus de cœurs que physiquement présents. Cela peut considérablement améliorer les performances en augmentant la parallélisation.

La mise en garde ici est que chaque version de SQL Server a ses propres limites sur la puissance de calcul qu'il peut utiliser. Pour plus d'informations, voir calcul des limites de capacité par édition de SQL Server.

Il existe deux options de licence pour SQL Server. Le premier est connu sous le nom de modèle serveur + licence d'accès client (CAL) ; le second est le modèle par cœur de processeur. Bien que vous puissiez accéder à toutes les fonctionnalités du produit disponibles dans SQL Server avec la stratégie serveur + CAL, il existe une limite matérielle de 20 cœurs de processeur par socket. Même si vous disposez de SQL Server Enterprise Edition + CAL pour un serveur avec plus de 20 cœurs de processeur par socket, l'application ne peut pas utiliser tous ces cœurs à la fois sur cette instance.

L'image ci-dessous montre le message du journal SQL Server après le démarrage indiquant l'application de la limite de noyau.

Par conséquent, pour utiliser tous les CPU, vous devez utiliser la licence par cœur de processeur. Pour plus d'informations sur les licences SQL Server, reportez-vous à la section "SQL Server 2022 : une plateforme de données moderne".

Il est peu probable que vous ayez à modifier les valeurs par défaut de l'affinité du processeur à moins que vous ne rencontriez des problèmes de performances, mais il est toujours utile de comprendre ce qu'elles sont et comment elles fonctionnent.

SQL Server prend en charge l'affinité de processeur par deux options :

SQL Server utilise tous les processeurs disponibles dans le système d'exploitation (si la licence par processeur est choisie). Il crée également des planificateurs f0r chaque CPU pour optimiser l'utilisation des ressources pour une charge de travail donnée. En mode multitâche, le système d'exploitation ou d'autres applications du serveur peuvent basculer les threads de traitement d'un processeur à un autre. SQL Server est une application qui consomme beaucoup de ressources et les performances peuvent en être affectées. Pour minimiser l'impact, vous pouvez configurer les processeurs de sorte que toute la charge SQL Server soit dirigée vers un groupe de processeurs présélectionné. Pour ce faire, utilisez le masque d'affinité du processeur.

L'option de masque d'E/S d'affinité lie les E/S de disque SQL Server à un sous-ensemble de processeurs. Dans les environnements OLTP SQL Server, cette extension peut considérablement améliorer les performances des threads SQL Server exécutant des opérations d'E/S.

Par défaut, SQL Server utilise tous les CPU disponibles pendant l'exécution d'une requête si la licence par cœur de processeur est choisie.

Bien que cela soit utile pour les requêtes volumineuses, il peut causer des problèmes de performances et limiter la simultanéité. Une meilleure approche consiste à limiter le parallélisme au nombre de cœurs physiques dans un seul socket de processeur. Par exemple, sur un serveur doté de deux sockets CPU physiques avec 12 cœurs par socket, quel que soit l'hyperthreading, MAXDOP doit être défini sur 12. MAXDOP Impossible de restreindre ou de dicter le CPU à utiliser. Elle limite le nombre de processeurs pouvant être utilisés par une seule requête de lot.

L'option max worker threads permet d'optimiser les performances lorsqu'un grand nombre de clients sont connectés à SQL Server.

Normalement, un thread de système d'exploitation distinct est créé pour chaque requête. Si des centaines de connexions simultanées sont effectuées sur SQL Server, la configuration à un thread par requête peut consommer un excès de ressources système. Cette max worker threads option permet d'améliorer les performances en permettant à SQL Server de créer un pool de threads de travail pouvant traiter collectivement un plus grand nombre de requêtes.

La valeur par défaut est 0, ce qui permet à SQL Server de configurer automatiquement le nombre de threads de travail au démarrage. Cela fonctionne pour la plupart des systèmes. Max worker threads est une option avancée qui ne doit pas être modifiée sans l'aide d'un administrateur de base de données expérimenté (DBA).

Quand devez-vous configurer SQL Server pour utiliser davantage de threads de travail ? Si la longueur moyenne de la file d'attente de travail de chaque planificateur est supérieure à 1, vous pouvez bénéficier de l'ajout de threads supplémentaires au système, mais uniquement si la charge n'est pas liée au processeur ou si d'autres files d'attente importantes sont en cours. Si l'une ou l'autre de ces opérations se produit, l'ajout de threads n'est pas utile, car ils finissent par attendre les autres goulets d'étranglement du système. Pour plus d'informations sur le nombre maximal de threads de travail, reportez-vous à la section "Configurez l'option Configuration du serveur max worker threads".