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

我最近查看了我的生產 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) Enterprise Edition：（64 位）在 Windows Server 2016 Datacenter 10.0（內部版本 14393：）（管理程序）上

並行的成本門檻值設置為 1400。未啟用

超執行緒。 最大並行度設置為 8。

如果您將最大並行度設置為零（這是預設設置），則可能受益於並行度的查詢將消耗 32 個執行緒。將工作人員數量設置為 960，這也是您設置的預設值，您只能同時執行 30 個並行查詢。

我建議將最大並行度設置為合理的值，例如 8。

SQL Server 的“執行緒池”並不總是由 Windows 中的真實執行緒完全支持。您可能會將其視為“邏輯執行緒池”。執行緒對象本身需要記憶體，如果有一段時間沒有使用，它們最終會被釋放回 Windows。

您所看到的是一個“執行緒加速”時期——在工作執行緒上等待通過 Windows API 實際分配執行緒的請求將導致相當短的THREADPOOL等待。

當您看到THREADPOOL這樣的短暫等待時，通常是因為您的工作量突然爆發或增加，可能是在一段時間的閒置（或只是較低的活動）之後。

這是正常的預期行為 - 但如果您不熟悉它會有點混亂！

我已經在我的部落格上寫過這個，包括一個展示，如果你想向自己“證明”這種行為：

異常的 THREADPOOL 等待

引用自：https://dba.stackexchange.com/questions/255417