Pourquoi ai-je des attentes THREADPOOL alors que des threads sont disponibles?

Aug 16 2020

Nous constatons des délais d'application et avec l'aide du kit de premier répondant, j'ai capturé les détails. L'une des choses qui a attiré mon attention était:

Attente empoisonnée détectée: pool de threads

J'ai donc couru ci-dessous les requêtes:

---get thread pool waits---thread pool wait query
SELECT count(*) FROM sys.dm_os_waiting_tasks 
 where wait_type ='threadpool'

-- get threads available--Threads available query
 declare @max int
select @max = max_workers_count from sys.dm_os_sys_info

select 
    @max as 'TotalThreads',
    sum(active_Workers_count) as 'CurrentThreads',
    @max - sum(active_Workers_count) as 'AvailableThreads',
    sum(runnable_tasks_count) as 'WorkersWaitingForCpu',
    sum(work_queue_count) as 'RequestWaitingForThreads' ,
    sum(current_workers_count) as 'AssociatedWorkers',
    Getdate() as 'DateLogged'
from  
    sys.dm_os_Schedulers where status='VISIBLE ONLINE'

Lorsque j'exécute la requête "attente de pool de threads", les attentes de pool de threads apparaissent dans le résultat ci-dessus (parfois plus de 20 résultats) pendant une fraction de seconde, puis disparaissent lorsque je l'exécute à nouveau. Mais je pouvais voir plus de 400 threads disponibles dans le deuxième jeu de résultats via la requête "threads available".

Je ne suis pas en mesure de comprendre pourquoi je vois des THREADPOOLattentes lorsque j'exécute la première requête, mais la deuxième requête montre que les threads sont toujours disponibles. Quelqu'un peut-il expliquer?

  • Maxdop: 8
  • Degré maximum de parallélisme: 50

Le pool de threads attend:

Réponses

4 JoshDarnell Aug 27 2020 at 21:38

Je ne peux pas comprendre pourquoi je vois que THREADPOOL attend lorsque j'exécute la première requête, mais la deuxième requête montre que les threads sont toujours disponibles. Quelqu'un peut-il expliquer?

J'ai observé que vous pouvez voir beaucoup d' THREADPOOLattentes très brèves (une poignée de millisecondes chacune) pendant que SQL Server acquiert des threads du système d'exploitation.

Cela peut se produire si, par exemple, SQL Server est resté inactif pendant un certain temps et que plusieurs requêtes parallèles sont exécutées simultanément. Ces requêtes devront attendre pendant que le système d'exploitation fournit des threads au processus sqlservr.exe, accumulant des THREADPOOLattentes pendant ce temps.

Vous pouvez confirmer que cela se produit en regardant le compteur PerfMon "Process" -> "Thread Count". En règle générale, chaque fois que cette valeur augmente rapidement, vous pouvez voir ces THREADPOOLattentes.

Il y a une démo complète de ce comportement sur mon blog ( Unusual THREADPOOL Waits ), voici le résumé:

Pour revenir à ce lien vers la documentation:

Se produit lorsqu'une tâche attend l'exécution d'un worker.

Dans le cas typique, cela est dû au fait que nous avons atteint la limite logique définie par SQL Server pour le nombre de threads de travail que vous pouvez avoir à la fois.

Dans le cas inhabituel, la tâche attend un travailleur car SQL Server alloue le thread (le demandant au système d'exploitation) qui est nécessaire pour sauvegarder ce travailleur.

Pour être clair, je serais surpris si ces attentes étaient à l'origine des délais d'attente de votre application.