SQL Server 遇到 THREADPOOL 等待，但仍有大量可用工作线程

Question

我最近查看了我的生产 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) - 13.0.5426.0 (X64) 企业版：（64 位）Windows Server 2016 Datacenter 10.0（内部版本 14393：）（管理程序）

并行的成本阈值设置为 1400。未启用
超线程。 最大并行度设置为 8。

Answer 1

如果将最大并行度设置为零（默认值），则可能受益于并行性的查询将消耗 32 个线程。当工作线程数设置为 960（同样是设置的默认值）时，您只能同时运行 30 个并行查询。

我建议将最大并行度设置为合理的值，例如 8。