Microsoft SQL sys.dm_os_wait_stats在時間段內累計的毫秒數多達

這篇文章的目的是最終確定一個SQL服務器框的CPU和IO利用率。傳統上，我們會使用@@ cpu_busy，@@ io_busy和@@ idle來確定無論在MSSQL上，那些在28天后都停止工作。我們從盒子上的不同來源獲得CPU利用率，但是我們需要確定IO界限。Microsoft SQL sys.dm_os_wait_stats在時間段內累計的毫秒數多達

查看sys.dm_os_wait_stats中的數據並每隔十分鐘計算一次增量值時，等待的秒數可能會超過10分鐘。我也嘗試按等待的任務劃分，但數據仍然沒有意義。
基本上，我們希望每個等待類型都變成百分比等待十分鐘的時間。但是如果等待時間超過十分鐘，那麼人們不能簡單地將時間分成10分鐘來查看所使用的百分比。

我們正在試圖確定一個度量來顯示一個盒子的IO限制。

https://msdn.microsoft.com/en-us/library/ms179984.aspx

wait_type =等待類型的名稱。有關更多信息，請參閱本主題後面的等待類型。

waiting_tasks_count =等待這個等待類型的次數。該計數器在每次等待開始時遞增。

wait_time_ms =此等待類型的總等待時間，以毫秒爲單位。

編輯

第一個答案是正確的軌道上，但不完全是。統計數據顯示，在給定的時間間隔內，可以歸因於任何一種特定等待類型的等待百分比。請參閱下圖。基於增量超過10分鐘的時間間隔

Graph of deltas compared to iobusy

EDIT

相關矩陣：

 
       wait_time_ms wait.NO.signal signal_wait_time @@io_busy @@cpu_busy ioPct cpuPct 
wait_time_ms    100   100    70  74   58 71  58 
wait.NO.signal   100   100    64  72   53 69  53 
signal_wait_time   70    64    100  71   89 67  89 
@@io_busy     74    72    71  100   77 99  77 
@@cpu_busy     58    53    89  77   100 75 100 
ioPct      71    69    67  99   75 100  75 
cpuPct      58    53    89  77   100 75 100

在上述圖中，可以看到，所述信號時間被最高度與相關@@ cpu_busy tick tick deltas。等待時間與@@ io_busy counter deltas最相關。

根據@@ vars，這個SQL框是cpu綁定的（cpu％比io％高很多），而根據等待統計信息，它是IO綁定的。根據sys.dm_os_ring_buffers那個框是CPU綁定的。我相信SystemHealth/SystemIdle說的是什麼。

本文建議可以使用信號等待時間與等待時間來獲得CPU壓力百分比。但是，與@@ cpu_busy數據相比，我強烈懷疑他的結論只是部分正確。如果他的cpuPressure％很高，是的，增加CPU的能力會有所幫助，但這不是全部。 http://blogs.msdn.com/b/sqlcat/archive/2005/09/05/461199.aspx

 
       wait_time_ms cpuPress wait.NO.signal signal_wait_time @@io_busy @@cpu_busy ioPct cpuPct 
cpuPress     -50  100   -56    25   -11   25 -11  25

編輯

爲的選擇框之一下面的作品，但考慮到不同的核心，我們將不得不因素是英寸

 

summary(m) 

Call: 
lm(formula = ioPct ~ cpuPct + signal_wait_time + wait_time_ms, 
    data = rd) 

Residuals: 
    Min  1Q Median  3Q  Max 
-3.13921 -0.75004 -0.07748 0.60897 2.14655 

Coefficients: 
         Estimate  Std. Error t value  Pr(>|t|)  
(Intercept)  -0.442311370934 0.085652949324 -5.164 0.000000286383 xxx 
cpuPct   0.123717691895 0.004503995334 27.468  less 2e-16 xxx 
signal_wait_time -0.000000302969 0.000000046933 -6.455 0.000000000161 xxx 
wait_time_ms  0.000000022240 0.000000002534 8.777  less 2e-16 xxx 
--- 
Signif. codes: 0 ‘xxx’ 0.001 ‘xx’ 0.01 ‘x’ 0.05 ‘.’ 0.1 ‘ ’ 1 

Residual standard error: 0.9959 on 1109 degrees of freedom 
Multiple R-squared: 0.7566, Adjusted R-squared: 0.7559 
F-statistic: 1149 on 3 and 1109 DF, p-value:

來源

2015-05-22 Chris

常規Microsoft SQL上是否提供了sys.dm_db_resource_stats？ https://msdn.microsoft.com/zh-cn/library/dn800981.aspx – Chris

在多核心機器，每個CPU都有自己的調度程序，並可以註冊自己的等待。例如 - 如果您有跨多個CPU並行運行的查詢，則並行查詢的每個部分都可以在等待查詢完成時註冊自己的CXPACKET等待。

爲了讓你的百分比得到利用，除以你的總等待時間，而不是10分鐘。

SELECT wait_type, 
     wait_time_ms * 100.00/SUM(wait_time_ms) OVER() 
FROM sys.dm_os_wait_stats

來源

2015-05-22 13:28:44

非常感謝！非常有幫助，但答案是正確的，但並不完全。統計數據顯示，在給定的時間間隔內，可以歸因於任何一種特定等待類型的等待百分比。我編輯了問題並添加了一個圖表。我覺得我們很接近。 – Chris

的等待統計數據是由工人（線程即）註冊。如果在一秒鐘內，10個線程暫停（每個）0.9秒並執行0.1秒，則總共等待時間（即9秒）和10x0.1總CPU時間（經過1秒）爲10x0.9。 100％cpu 和高等待時間（無論等什麼）。

高信號等待時間表示CPU爭用。在線程有機會運行之前，線程需要等待更長的時間，以等待信號發出。

來源

2015-05-22 19:41:28

Microsoft SQL sys.dm_os_wait_stats在時間段內累計的毫秒數多達

回答

相關問題