¿Por qué tengo THREADPOOL esperas aunque tengo hilos disponibles?
Estamos viendo tiempos de espera de aplicaciones y, con la ayuda del kit de primeros auxilios, he capturado los detalles. Una de las cosas que me llamó la atención fue:
Espera de veneno detectada: grupo de subprocesos
Así que ejecuté las siguientes consultas:
---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'
Cuando ejecuto la consulta "espera del grupo de subprocesos", las esperas del grupo de subprocesos aparecen en el resultado anterior (a veces, más de 20 resultados) durante una fracción de segundo y luego desaparecen cuando lo vuelvo a ejecutar. Pero pude ver más de 400 hilos disponibles en el segundo conjunto de resultados a través de la consulta "hilos disponibles".
No puedo entender por qué veo THREADPOOL
esperas cuando ejecuto la primera consulta, pero la segunda consulta muestra que los subprocesos todavía están disponibles. ¿Alguien puede explicarme?
- Maxdop: 8
- Grado máximo de paralelismo: 50
El grupo de subprocesos espera:


Respuestas
No puedo entender por qué veo que THREADPOOL espera cuando ejecuto la primera consulta, pero la segunda consulta muestra que los subprocesos todavía están disponibles. ¿Alguien puede explicarme?
He observado que puede ver muchas THREADPOOL
esperas realmente breves (un puñado de milisegundos cada una) mientras SQL Server adquiere subprocesos del sistema operativo.
Esto podría suceder si, por ejemplo, SQL Server estuvo inactivo durante un tiempo y luego se ejecutan varias consultas paralelas a la vez. Estas consultas deberán esperar mientras el sistema operativo proporciona subprocesos al proceso sqlservr.exe, acumulando THREADPOOL
esperas durante ese tiempo.
Puede confirmar que esto está sucediendo observando el contador de PerfMon "Proceso" -> "Recuento de subprocesos". Generalmente, siempre que este valor suba rápidamente, es posible que vea estas THREADPOOL
esperas.
Hay una demostración completa de este comportamiento en mi blog ( Esperas inusuales de THREADPOOL ), aquí está el resumen:
Volviendo a ese enlace de documentos:
Ocurre cuando una tarea está esperando a que se ejecute un trabajador.
En el caso típico, esto se debe a que hemos alcanzado el límite lógico establecido por SQL Server para la cantidad de subprocesos de trabajo que puede tener a la vez.
En el caso inusual, la tarea está esperando a un trabajador porque SQL Server está asignando el hilo (solicitándolo al sistema operativo) que se necesita para respaldar a ese trabajador.
Para ser claros, me sorprendería si estas esperas fueran la causa de los tiempos de espera de su solicitud.