初涉SQL Server效能問題（1/4）

標籤：

當你作為DBA時，很多人會向你抱怨：“這個程式資料載入和蝸牛一樣，你看看是不是伺服器出問題了？”造成這個問題的原因有很多。可能是程式應用伺服器問題，網路問題，程式實現方式問題，資料庫伺服器負荷過重。不管是哪個問題，資料庫總是第一個被抱怨的。我們DBA的職責就是找出問題所在，並解決它們。

問題解決第一步，診斷分析：

1 SELECT 2 parent_node_id                  AS Node_Id,3 COUNT(*)                        AS [No.of CPU In the NUMA],4 SUM(COUNT(*)) OVER()            AS [Total No. of CPU],5 SUM(runnable_tasks_count )      AS [Runnable Task Count], 6 SUM(pending_disk_io_count)                    AS [Pending disk I/O count],7 SUM(work_queue_count)          AS  [Work queue count]8 FROM sys.dm_os_schedulers WHERE status=‘VISIBLE ONLINE‘ GROUP BY parent_node_id

返回結果說明：

• 如果返回的是一條記錄，說明伺服器不支援NUMA架構，否則記錄數就是NUMA架構的節點數（NUMA：非均勻訪存模型）。
• Node_id：NUMA節點id。
• No.of CPU in the NUMA：分配給NUMA節點的CPU數，或調度數（ number of schedulers）。
• Total No. of CPU：伺服器上可用CPU總數。
• Runnable Task Count：在可運行隊列裡，等待被重現調度的，用於分配任務（tasks）的工作者（workers）數。即，可運行隊列裡請求數。
• Pending disk I/O count：等待被完成的等待IO數。每個調度都有一個等待IO清單，用於判斷它們在環境切換時是否完成。當請求被插入時，這個數字會增加。請求完成後，數字會減少。
• Work queue count：等待隊列裡的任務數。這些任務等待工作者拿走。

我會把這個指令碼的輸出結果存到一張表，並設定為計劃任務每10分鐘運行一次，收集運行2天。這樣我們對伺服器的健全狀態就有了基本的瞭解。在我測試的伺服器上，當Runnable Task Count一直在10的時候，使用者就是抱怨伺服器慢！正常情況，每個節點的這個數字應該低於10。這就給了我們當前系統啟動並執行大致情況。如果這一步的輸出結果是正常的，我們就可以排除資料庫伺服器的問題了，響應慢的問題可能是我們不能控制的阻塞造成的，或者只是部分會話響應慢，而不是整個伺服器慢。

這就是我們第1步的問題分析診斷方法，接下來的文章會具體解釋後續該如何處理。

附圖2張，協助大家理解任務（tasks）、工作者（works）、調度（schedulers）之間的關係。

對於每個CPU，SQLSERVER都會有一個scheduler與之對應。在每個scheduler裡，會有若干個worker，對應於每個線程。在用戶端發過來請求之後，SQL會將其分解成一個或多個task。根據每個scheduler的繁忙程度，task會被分配到某個scheduler上。如果scheduler裡有閒置worker，task就會被分配到某個worker上。如果沒有，scheduler會建立新的worker，供task使用。如果scheduler裡的worker已經到了他的上限值，而他們都有task要運行，那麼新的task只好進入等待worker的狀態。 

 

初涉SQL Server效能問題（1/4）