CONTEXTE J'ai récemment étudié des temps d'attente assez élevés pour CXPacket, ce qui m'a obligé à utiliser SQL Sentry pour surveiller de près l'activité du processeur.
Une chose que j'ai remarquée en conséquence est que nous avons des pics massifs dans le changement de contexte. Vous trouverez ci-dessous un échantillon de 5 minutes, mais ce schéma est très courant tout au long de la journée.
Comme vous pouvez le voir, il augmente assez régulièrement. Maintenant, ma compréhension de cela me ferait croire que ce serait le résultat de la pression du processeur. Cependant, pendant ce temps, à peine plus de 60%.
Après quelques recherches, cela m'a amené à croire que cela se produit en raison de l'hyper threading. Je sais que j'avais lu plus tôt certains des dangers de l'hyper threading. Mais cela a été écrit il y a très longtemps.
Pour faire court. L'hyper threading est-il susceptible d'être le coupable de ces pics de changement de contexte? Est-il possible que le changement de contexte ait un impact négatif sur mes requêtes parallèles? Dois-je désactiver l'hyper threading dans mon environnement?
MISE À JOUR bien que cette chose spécifique se passe dans mon environnement, la question en son cœur est plus universelle. Dans quelle mesure des niveaux élevés de changement de contexte peuvent-ils avoir un impact sur les requêtes parallèles? L'hyper threading peut-il provoquer ce genre de problème?
En fin de compte, la plupart de ce que je trouve sur Internet suggère que l'hyper threading et SQL Server ne sont pas de bons amis, mais la plupart sont que les informations sont extrêmement datées.
Mon système Il y avait beaucoup de questions de configuration, je vais donc y répondre ici afin qu'elles puissent être exclues. Nous avons les paramètres d'alimentation sur les performances au niveau du système d'exploitation et de la bio. Notre Maxdop est réglé sur 8 et le seuil de coût pour le parallélisme est de 25. Nous avons 32 cœurs logiques et 16 physiques. Il s'agit également pour la plupart d'un scénario de chargement d'entrepôt de données.
Réponses:
Indique souvent rien de plus que le fait que certaines requêtes s'exécutent avec parallélisme; Les attentes de CXPACKET sur le serveur ne sont pas un signe immédiat de problèmes, bien qu'elles puissent être le symptôme d'un autre problème.
Si le serveur héberge un entrepôt de données ou un type de base de données de rapports qui reçoit un faible volume de requêtes mais traite de grandes quantités de données, le parallélisme peut réduire considérablement le temps nécessaire pour exécuter ces requêtes. En revanche, cependant, si le serveur héberge une base de données OLTP contenant de nombreuses petites requêtes et transactions, le parallélisme peut tuer le débit et avoir un impact négatif sur les performances.
Dans la mesure du possible, il est préférable d'isoler et de dépanner le type d'attente sous-jacent, car cela entraînera des améliorations globales du débit du système. Encore une fois, les attentes CXPACKET sont simplement un symptôme d'un problème dans la plupart des cas, pas le problème réel
Le DMV sys.dm_os_latch_stats contient des informations sur les attentes de verrou spécifiques qui se sont produites dans l'instance, et si l'un des verrous supérieurs attend est ACCESS_METHODS_DATASET_PARENT, conjointement avec CXPACKET, LATCH_ * et SOS_SCHEDULER_YIELD, les types d'attente comme niveau d'attente supérieur, le niveau de le parallélisme sur le système est la cause d'un goulot d'étranglement lors de l'exécution des requêtes, et la réduction de l'option sp_configure «degré maximal de parallélisme» peut être nécessaire pour résoudre les problèmes.
Cet article de TechNet Magazine est ancien mais il dit d'essayer de désactiver l'hyperthreading si vous dépassez les 5000 par seconde et par processeur:
Optimisation des performances du processeur SQL Server par Zach Nichter
la source