小编Mik*_* P.的帖子

我最近查看了我的生产 SQL Server 的累积线程池等待时间，这确实是几天的等待时间。所以我开始做一些挖掘。

我在 32 核 64 位服务器上（在 EC2 上运行）。Max workers 在配置中正确设置为 0，以下 DMV 报告了正确的预期数字：

SELECT max_workers_count FROM sys.dm_os_sys_info

Output: 960

看看我的工人总数，我很少看到超过 300-400 的：

SELECT count(*) FROM sys.dm_os_workers

Output: 372

然而，如果我运行以下 DMV，我总是会列出线程：

SELECT * FROM sys.dm_os_waiting_tasks
WHERE wait_type = 'THREADPOOL'

SELECT dow.state , dow.is_preemptive , dow.is_sick , dow.is_in_polling_io_completion_routine , [Num Workers] = COUNT(1) 
FROM sys.dm_os_workers dow 
GROUP BY dow.state , dow.is_preemptive , dow.is_sick , dow.is_in_polling_io_completion_routine;

以毫秒为单位的等待通常很短，一般为 20-200 毫秒，它们也很快消失，但它们增加了整体累积线程池数字。他们也从来没有阻塞会话。

当我有这么多可用的工作人员时，我很困惑为什么会遇到线程池等待。数百个可用的工作人员不应该在没有任何线程进入线程池的情况下立即处理这些请求吗？

我很感激这里的任何输入或方向。

SQL Server 版本：SQL Server 2016 (SP2-CU8) (KB4505830) …