【SQLServer】max worker threads參數說明

• 2022 年 9 月 11 日
• 筆記
• SQLServer

本文介紹如何使用SQL Server Management Studio或Transact-SQL在SQL Server中配置最大工作執行緒伺服器配置選項。

max worker threads選項配置SQL Server可用於處理查詢請求、登錄、註銷和類似應用程式請求的工作執行緒數。

SQL Server使用作業系統的本地執行緒服務來確保以下條件：
·一個或多個執行緒同時支援SQL Server支援的每個網路。
·一個執行緒處理資料庫檢查點。
·一個執行緒池處理所有用戶。

max worker threads的默認值為0。這使SQL Server能夠在啟動時自動配置工作執行緒數。默認設置適合大多數系統。但是，根據你的系統配置，將最大工作執行緒數設置為特定值有時會提高性能。

查詢請求的實際數量可能會超過max worker threads中設置的值，在這種情況下，SQL Server將工作執行緒池化，以便下一個可用的工作執行緒可以處理請求。工作執行緒僅分配給活動請求，並在請求得到服務後釋放。即使發出請求的用戶會話/連接保持打開，也會發生這種情況。

max worker threads配置選項不會限制引擎內可能產生的所有執行緒。LazyWriter、Checkpoint、Log Writer、Service Broker、Lock Manager或其他任務所需的系統執行緒在此限制之外生成。可用性組使用max worker threads限制內的一些工作執行緒，但如果超過配置的執行緒數，也使用系統執行緒，以下查詢將提供有關係統任務產生的額外執行緒資訊。

SELECT  
s.session_id,  
r.command,  
r.status,  
r.wait_type,  
r.scheduler_id,  
w.worker_address,  
w.is_preemptive,  
w.state,  
t.task_state,  
t.session_id,  
t.exec_context_id,  
t.request_id  
FROM sys.dm_exec_sessions AS s  
INNER JOIN sys.dm_exec_requests AS r  
    ON s.session_id = r.session_id  
INNER JOIN sys.dm_os_tasks AS t  
    ON r.task_address = t.task_address  
INNER JOIN sys.dm_os_workers AS w  
    ON t.worker_address = w.worker_address  
WHERE s.is_user_process = 0;

以下是設置建議：

此選項是一個高級選項，只能由經驗豐富的資料庫管理員或經過認證的SQL Server專業人員進行更改。如果你懷疑存在性能問題，有可能不是工作執行緒的可用性原因。原因更可能與佔用工作執行緒而不釋放它們的活動有關。比如長時間運行的查詢或瓶頸（I/O、阻塞、閂鎖等待、網路等待）。最好在更改最大工作執行緒設置之前找到性能問題的根本原因。

當大量客戶端連接到伺服器時，執行緒池有助於優化性能。通常，會為每個查詢請求創建一個單獨的作業系統執行緒。但是，對於數百個與伺服器的連接，每個查詢請求使用一個執行緒會消耗大量系統資源。max worker threads選項使SQL Server能夠創建一個工作執行緒池來服務更多的查詢請求，從而提高性能。

下表顯示了根據CPU、電腦體系結構和SQL Server版本的各種組合自動配置的最大工作執行緒數（當值設置為0時），使用公式：默認最大工作執行緒數+((邏輯CPU-4)*每個CPU的worker執行緒數)

 截至SQL Server 2016 (13.x) SP1,每個CPU的worker執行緒數取決於cpu的架構(32位還是64位)：

 從SQL Server 2016 (13.x) SP2和SQL Server 2017 (14.x)起，每個CPU的worker執行緒數取決於cpu的架構(32位還是64位)和處理器的個數：

當所有工作執行緒都在長時間運行的查詢中處於活動狀態時，SQL Server可能會顯示為無響應，直到工作執行緒完成並變得可用。雖然這不是缺陷，但有時可能是不可取的。如果某個進程似乎沒有響應並且無法處理新查詢，則使用專用管理員連接(DAC)連接到SQL Server，並終止該進程。為防止這種情況，請增加最大工作執行緒數。