初涉SQL Server性能問題（1/4）：服務器概況

 

當你做爲DBA時，不少人會向你抱怨：「這個程序數據加載和蝸牛同樣，你看看是否是服務器出問題了？」形成這個問題的緣由有不少。多是程序應用服務器問題，網絡問題，程序實現方式問題，數據庫服務器負荷太重。無論是哪一個問題，數據庫老是第一個被抱怨的。咱們DBA的職責就是找出問題所在，並解決它們。

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

 

SELECT 
parent_node_id                  AS Node_Id,
COUNT(*)                        AS [No.of CPU In the NUMA],
SUM(COUNT(*)) OVER()            AS [Total No. of CPU],
SUM(runnable_tasks_count )      AS [Runnable Task Count], 
SUM(pending_disk_io_count)                    AS [Pending disk I/O count],
SUM(work_queue_count)          AS  [Work queue count]
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的狀態。 

 

 

注：此文章屬WoodyTu原創，版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接！