wait_type SOS_WORKER導致資料庫連線失敗

ywxj_001發表於2020-02-17

SQLServer資料庫system_health:event_file:

有資料庫鎖。

wait_type SOS_WORKER導致資料庫連線失敗

wait_type SOS_WORKER導致資料庫連線失敗

資料庫日誌報錯:

The client was unable to reuse a session with SPID 2799, which had been reset for connection pooling. The failure ID is 46. This error may have been caused by an earlier operation failing. Check the error logs for failed operations immediately before this error message.

wait_type SOS_WORKER導致資料庫連線失敗

還有wait_type   SOS_WORKER

資料庫做統計資訊收集導致查詢SQL的鎖等待,wait_type    LCK_M_SCH_S

最終耗盡資料庫執行緒池的執行緒,導致資料庫會話連線失敗。



這個等待型別出現是因為伺服器的執行緒池(Thread Pool)沒有可用的執行緒,它可能導致登入失敗或SQL語句無法正常執行。


當任務在等待工作執行緒(worker thread)執行時出現這個等待事件。這可能表明資料庫引數max worker threads的值設定

過低, 或者批處理執行時間過長, 從而減少了可用於滿足其它批處理的工作執行緒(worker thread)數量。(舉個生活當中的

例子,當你去飯店吃飯,工作執行緒好比餐廳的服務員,例如服務員過少或某些顧客佔用服務員的時間過長,那麼就會出現很

多顧客鬱悶地長時間等待服務的現象。)




這個等待型別在sys.dm_xe_map_vlaues中對應的擴充套件事件為SOS_WORKER




SQL Server例項在啟動的時候建立了一定數量的工作執行緒(workder threads),舉個例子, 我的筆記本的CPU有8個邏輯

處理器,因此SQL Server例項啟動的時候建立了576個工作執行緒。你可以從sys.dm_os_sys_info 這個DMV檢視中的

max_worker_count列檢視你的例項分配了多少工作執行緒。




在[sys].[dm_os_sys_info]可以查到:


CPU和max_workers_count對應關係(系統自動分配):


CPU 32核對應max_workers_count為960


CPU 64核對應max_workers_count為1472


最大工作執行緒數為0,表示系統自動分配。(如上根據CPU核數自動分配最大工作執行緒數)

wait_type SOS_WORKER導致資料庫連線失敗



當一個查詢去執行時,SQL Server會決定需要多少個執行緒,並且決定為執行緒池(thread pool)保留多少個執行緒。 

如果沒有足夠可用的執行緒,此時threadpool 等待就會出現,如果沒有可用的執行緒, 連線到SQL Server就會失敗。




可能有多種原因導致工作執行緒發生飢餓現象(Worker thread starvation),包括下面一些情況:



一個執行緒獲取了一個鎖,然後導致其它執行緒被阻塞,越來越多的連線出現並被阻塞,最終耗盡了執行緒池(thread pool)

中的執行緒。


這種情況可以從sys.dm_os_waiting_tasks 這個DMV檢視中(使用我的指令碼)找出被單個SPID阻塞的記錄,並考慮將其殺死。


並行查詢計劃正在被數百個連線執行,耗盡了執行緒池中執行緒。


檢視CXPACKET等待並標識那些並行執行計劃的SQL語句,儘可能減少並行的總量發生。


一個查詢計劃正在被許多連線執行,並且查詢時間比平時要長,耗盡了執行緒池的執行緒。


查詢CXPACKET等待並如何識別偏斜平行度(skewed parallelism)。


還要查詢那些長時間執行的查詢語句,並調查發生了什麼等待以檢視是否存在常規效能問題導致執行緒匱乏,或者那些長時間

執行的SQL語句是否有不正確的查詢計劃。




SQL Server中的活動會話數等於工作執行緒數


檢查sys.dm_exec_requests檢視中的記錄數,如果記錄數接近工作執行緒數量, 減少連線數量(例如,應用程式是否沒有使

用連線池或沒有正確關閉)或增加max worker threads的值。請注意,由於空閒連線不消耗工作執行緒,因此與SQL Server

連線的數量可能超過活動(Active)的連線,這可能是完全正常的。

dm_exec_requests:包含sleeping狀態的會話(真實的資料庫會話連線數,佔用工作執行緒)

dm_exec_sessions:不包含sleeping狀態的會話


對max worker thread引數的不正確配置。


檢視max worker worker thread 選項的值並設定為自動調整。


如果由於工作執行緒不足(worker thread starvation)無法連線到SQL Server去進行故障診斷,請嘗試使用專用管理員連線

(DAC)。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/22996654/viewspace-2675926/,如需轉載,請註明出處,否則將追究法律責任。

相關文章