【SQLServer】max worker threads引數說明

本文介紹如何使用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，並終止該程序。為防止這種情況，請增加最大工作執行緒數。