Perché ho THREADPOOL in attesa anche se ho thread disponibili?

Question

Stiamo assistendo a timeout delle applicazioni e con l'aiuto del kit First Responder, ho acquisito i dettagli. Una delle cose che ha attirato la mia attenzione è stata:

Rilevata attesa veleno: pool di thread

Quindi ho eseguito le seguenti query:

---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'

Quando eseguo la query "thread pool wait", le attese del thread pool vengono visualizzate nel risultato sopra (a volte, più di 20 risultati) per una frazione di secondo e poi scompaiono quando lo eseguo di nuovo. Ma ho potuto vedere più di 400 thread disponibili nel secondo set di risultati tramite la query "thread disponibili".

Non riesco a capire il motivo per cui vedo le THREADPOOLattese quando eseguo la prima query, ma la seconda query mostra che i thread sono ancora disponibili. Qualcuno può spiegare?

• Maxdop: 8
• Massimo grado di parallelismo: 50

Il pool di thread attende:

Answer 1

Non riesco a capire perché vedo THREADPOOL in attesa quando eseguo la prima query, ma la seconda query mostra che i thread sono ancora disponibili. Qualcuno può spiegare?

Ho osservato che puoi vedere molte THREADPOOLattese davvero brevi (una manciata di millisecondi ciascuna) mentre SQL Server acquisisce i thread dal sistema operativo.

Ciò potrebbe accadere se, ad esempio, SQL Server è rimasto inattivo per un po 'e quindi vengono eseguite più query parallele contemporaneamente. Queste query dovranno attendere mentre il sistema operativo fornisce thread al processo sqlservr.exe, accumulando THREADPOOLattese durante quel periodo.

Puoi confermare che ciò sta accadendo guardando il contatore PerfMon "Process" -> "Thread Count". In genere, ogni volta che questo valore sale rapidamente, potresti vedere queste THREADPOOLattese.

C'è una demo completa di questo comportamento sul mio blog ( Unusual THREADPOOL Waits ), ecco il riepilogo:

Tornando al link di quel documento:

Si verifica quando un'attività è in attesa dell'esecuzione di un worker.

Nel caso tipico, ciò è dovuto al fatto che abbiamo raggiunto il limite logico impostato da SQL Server per il numero di thread di lavoro che puoi avere contemporaneamente.

Nel caso insolito, l'attività è in attesa di un worker perché SQL Server sta allocando il thread (richiedendolo al sistema operativo) necessario per supportare quel worker.

Per essere chiari, sarei sorpreso se queste attese fossero la causa dei timeout dell'applicazione.