Hier, j'ai reçu un appel d'un client qui se plaignait d'une utilisation élevée du processeur sur son serveur SQL. Nous utilisons SQL Server 2012 64 bits SE. Le serveur exécute Windows Server 2008 R2 Standard, Intel Xeon 2,20 GHz (4 cœurs), 16 Go de RAM.
Après m'être assuré que le coupable était bien SQL Server, j'ai jeté un coup d'œil aux premières attentes pour l'instance à l'aide de la requête DMV ici . Les deux premières attentes étaient: (1) PREEMPTIVE_OS_DELETESECURITYCONTEXT
et (2) SOS_SCHEDULER_YIELD
.
EDIT : Voici le résultat de la "requête top attentes" (bien que quelqu'un ait redémarré le serveur ce matin contre mes souhaits):
Nous faisons beaucoup de calculs / conversion intenses, donc je peux comprendre SOS_SCHEDULER_YIELD
. Cependant, je suis très curieux de savoir le PREEMPTIVE_OS_DELETESECURITYCONTEXT
type d'attente et pourquoi il pourrait être le plus élevé.
La meilleure description / discussion que je peux trouver sur ce type d'attente peut être trouvée ici . Il mentionne:
Les types d'attente PREEMPTIVE_OS_ sont des appels qui ont quitté le moteur de base de données, généralement vers une API Win32, et exécutent du code en dehors de SQL Server pour diverses tâches. Dans ce cas, il supprime un contexte de sécurité précédemment utilisé pour l'accès aux ressources à distance. L'API associée est en fait nommée DeleteSecurityContext ()
À ma connaissance, nous n'avons pas de ressources externes comme des serveurs liés ou des filetables. Et nous ne faisons aucune usurpation d'identité, etc. Une sauvegarde aurait-elle pu provoquer un pic ou peut-être un contrôleur de domaine défectueux?
Que diable pourrait faire que ce soit le type d'attente dominant? Comment puis-je suivre ce type d'attente plus loin?
Edit 2: J'ai vérifié le contenu du journal de sécurité Windows. Je vois quelques entrées qui peuvent être intéressantes, mais je ne sais pas si elles sont normales:
Special privileges assigned to new logon.
Subject:
Security ID: NT SERVICE\MSSQLServerOLAPService
Account Name: MSSQLServerOLAPService
Account Domain: NT Service
Logon ID: 0x3143c
Privileges: SeImpersonatePrivilege
Special privileges assigned to new logon.
Subject:
Security ID: NT SERVICE\MSSQLSERVER
Account Name: MSSQLSERVER
Account Domain: NT Service
Logon ID: 0x2f872
Privileges: SeAssignPrimaryTokenPrivilege
SeImpersonatePrivilege
Edit 3 : @Jon Seigel, comme vous l'avez demandé, voici les résultats de votre requête. Un peu différent de celui de Paul:
Edit 4: Je l'avoue, je suis un premier utilisateur d'événements prolongés. J'ai ajouté ce type d'attente à l'événement wait_info_external et j'ai vu des centaines d'entrées. Il n'y a pas de texte sql ni de descripteur de plan, seulement une pile d'appels. Comment puis-je retrouver la source?
la source
Réponses:
Je sais que cette question, basée sur le titre, concerne principalement le type d'attente PREEMPTIVE_OS_DELETESECURITYCONTEXT, mais je pense que c'est une mauvaise direction du vrai problème qui est " un client qui se plaignait d'une utilisation élevée du processeur sur leur serveur SQL ".
La raison pour laquelle je crois que se concentrer sur ce type d'attente spécifique est une chasse aux oies sauvages, car elle augmente pour chaque connexion établie. J'exécute la requête suivante sur mon ordinateur portable (ce qui signifie que je suis le seul utilisateur):
Et puis je fais l'une des opérations suivantes et réexécute cette requête:
SQLCMD -E -Q "select 1"
Maintenant, nous savons que le CPU est élevé, nous devons donc regarder ce qui est en cours d'exécution pour voir quelles sessions ont un CPU élevé:
J'exécute généralement la requête ci-dessus telle quelle, mais vous pouvez également changer la clause ORDER BY qui est mise en commentaire pour voir si cela donne des résultats plus intéressants / utiles.
Vous pouvez également exécuter les éléments suivants, en fonction de dm_exec_query_stats, pour rechercher les requêtes les plus coûteuses. La première requête ci-dessous vous montrera des requêtes individuelles (même si elles ont plusieurs plans) et est triée par Temps CPU moyen, mais vous pouvez facilement changer cela en Lectures logiques moyennes. Une fois que vous avez trouvé une requête qui semble prendre beaucoup de ressources, copiez "sql_handle" et "statement_start_offset" dans la condition WHERE de la deuxième requête ci-dessous pour voir les plans individuels (peut être supérieur à 1). Faites défiler vers l'extrême droite et en supposant qu'il existe un plan XML, il s'affichera sous forme de lien (en mode Grille) qui vous amènera à la visionneuse de plan si vous cliquez dessus.
Requête n ° 1: obtenir des informations sur la requête
Requête n ° 2: Obtenir des informations sur le plan
la source
SecurityContext est utilisé par le serveur SQL à plusieurs endroits. Un exemple que vous avez nommé est les serveurs liés et les fichiers filetables. Peut-être que vous utilisez cmdexec? Tâches de l'Agent SQL Server avec des comptes proxy? Vous appelez un webservice? Les ressources distantes peuvent être très amusantes.
Les événements d'emprunt d'identité peuvent être enregistrés dans l'événement de sécurité Windows. Il se pourrait que vous y trouviez un indice. De plus, vous voudrez peut-être vérifier l'enregistreur de la boîte noire alias les événements étendus.
Avez-vous vérifié si ces types d'attente sont nouveaux (et en relation avec le processeur élevé) ou tout simplement normaux pour votre serveur?
la source