这篇文章的重点是最终确定 SQL 服务器机器的 CPU 和 IO 利用率。传统上我们会使用@@cpu_busy、@@io_busy 和@@idle 来确定，但是在 MSSQL 上，它们会在 28 天后停止工作。我们从盒子上的不同来源获得了 CPU 利用率，但我们需要确定 IO 限制。

查看 sys.dm_os_wait_stats 中的数据并每十分钟计算一次增量时，等待的秒数可能超过十分钟。 我也尝试除以等待的任务，但数据仍然没有意义。
基本上，我们希望将每种等待类型都变成十分钟内等待的百分比。但是，如果等待时间超过 10 分钟，则无法简单地将时间除以 10 分钟来查看使用百分比。

我们正在尝试确定一个指标来显示 IO 绑定(bind)框的情况。

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

wait_type = 等待类型的名称。有关详细信息，请参阅本主题后面的等待类型。

waiting_tasks_count = 此等待类型的等待次数。该计数器在每次等待开始时递增。

wait_time_ms = 此等待类型的总等待时间(以毫秒为单位)。

编辑

第一个答案在正确的轨道上，但不完全正确。该统计数据显示的是对于给定的时间间隔，可归因于任何一种特定等待类型的等待百分比。请参见下图。

编辑

基于超过 10 分钟间隔的增量的相关矩阵:

                 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 滴答计数器增量的相关性最高。等待时间与@@io_busy 计数器增量最相关。

根据@@vars，此 SQL 框受 cpu 限制(cpu% 比 io% 高很多)，而“根据”等待统计信息，它受 IO 限制。根据 sys.dm_os_ring_buffers ，该框受 CPU 限制。我相信 SystemHealth/SystemIdle 所说的。

这篇文章建议可以使用信号等待时间 vs 等待时间来获得 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: 

最佳答案

在多核机器上，每个 CPU 都有自己的调度器，并且可以注册自己的等待。例如 - 如果您有一个跨多个 CPU 并行运行的查询，则并行查询的每个部分都可以在等待查询完成时注册自己的 CXPACKET 等待。

要获得利用率，只需除以总等待时间，而不是 10 分钟。

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

关于sql-server - Microsoft SQL sys.dm_os_wait_stats 加起来比时间段多毫秒，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/30389242/