【4.6】基于Perfmon深入探究

【0】您能否仅使用Performance Monitor计数器来判断数据库是否变慢？

这是性能监视器信息：

Processor
　　%Processor Time = 65%
System
　　Processor Queue Length = 5
　　Context Switches/sec = 27000
Logical Disk
　　Average Disk Queue Length = 13
Memory
　　%Committed Bytes In Use = 48%
　　Available MB = 220
　　Page Faults/sec = 4000
SQL Buffer Manager
　　Page Life Expectancy = 140
　　Buffer cache hit ratio = 92%
　　Lazy Writer/sec = 0.5
SQL General Statistics
　　User Connections = 5200
SQL Statistics
　　Batch Requests/sec = 1000
　　SQL Compilations/sec = 70

• 处理器
  • 处理器时间百分比= 65％
• 系统名称
  • 队列处理器长度= 5
  • 上下文切换/秒= 27000
• 逻辑磁盘
  • 平均磁盘队列长度= 13
• 内存
  
  • 使用的已提交字节百分比= 48％
  • 可用MB = 220
  • 页面错误/秒= 4000
• SQL缓冲区管理器
  • 网页预期寿命= 140
  • 缓冲区高速缓存命中率= 92％
  • 惰性作家/秒= 0.5
• SQL一般统计
  • 用户连接= 5200
• SQL统计
  • 批处理请求/秒= 1000
  • SQL编译/秒= 70

 

【1】错误的监控意识

监控消耗：这很容易说，但是很难做到。让我们以DBA最常用的一些计数器（perfmon）为例：

Processor
　　%Processor Time = 65%
Logical Disk
　　Average Disk Queue Length = 13
SQL Buffer Manager
　　Page Life Expectancy = 140
　　Buffer cache hit ratio = 92%
　　Lazy Writer/sec = 0.5
SQL General Statistics
　　User Connections = 5200

• 处理器
  • 处理器时间百分比= 65％
• 逻辑磁盘
  • 平均磁盘队列长度= 13
• SQL缓冲区管理器
  • 网页预期寿命= 140
  • 缓冲区高速缓存命中率= 92％
  • 惰性作家/秒= 0.5
• SQL一般统计
  • 用户连接= 5200

【1.1】一时的指标代表性能不好嘛？错误的

所以我可以得出一些（错误的）结论：

1. CPU消耗相对较高，约为65％，这可能表明处理器太忙
2. 磁盘队列大于2。这可能表示严重的磁盘问题。
3. 预期页面寿命（PLE）计数器低于300，表明内存不足。
4. 缓冲区高速缓存命中率超过90％，表明内存不足不会影响系统
5. 登录的用户数量很多（5200），可能会导致系统负载。

这些只是基于观察值的假设。这些孤立的事实可以回答以下问题：我是否需要购买更多的CPU？我应该向数据库添加内存吗？登录的用户过多吗？您会建议使用SSD磁盘吗？

实际上不该基于此来做任何操作，应当以图表为例：

　　

【1.2】应该忘记数字，使用图表

分析冷数字很困难，因此只要有可能就使用图表。该图显示了指标的波动以及已更改的日期/时间。请参见“页面预期寿命”会计师的下表。在这种情况下，我们得出什么结论？

看来在上午10点，我们的使代价最小最低。

注意，分析仍然很困难。我可以提出两个有效但矛盾的说法：

1. 太好了！服务器运行良好。
2. 这样的服务器可以受益于增加的内存。

这里的一切都取决于比较的基础。如果我们将其与高负载服务器进行比较，可以说该服务器看起来不错（＃1）。

另一方面，如果我们将其与安静的服务器进行比较，则可以说该图可能更好（＃2）。

我的观点是，我们经常从性能监视器中得出错误的结论。

【1.3】perfmon对于监控的使用意义

Perfmon是监视数据库的基本工具，但不要将其用作主要的故障排除工具。

什么意思 想象一下，Perfmon等于（赛车）汽车的燃油表：

该仪表非常重要，因为我们无法达到零级。但是，通过单独查看该指标来确定汽车性能非常困难。以同样的方式考虑Perfmon：

• 不要用它来衡量系统性能
• 不要将其视为主要的调优工具。
• 不要基于此得出结论

Perfomance Monitor的正确用法是作为“比较基准”：

• 我在一月份会消耗更多资源吗？
• 优化后节省了多少资源？
• 我累了吗？

这是我前几天在服务器上进行的优化工作的一个示例：

CPU-之前 

CPU-之后 

看来收益正确吗？现在来看减少磁盘访问（越小越好）：

磁盘IOPS-之前 

磁盘IOPS-之后 

使用Performance Monitor进行比较很容易

【2】perfmon的七大核心监控指标

【2.1】Buffer Manager:Buffer Cache Hit Ratio

1.缓冲区管理器：缓冲区高速缓存命中率

缓冲区高速缓存命中率决定了内存高速缓存的效率，人们建议它要高于90％。该计数器的计算基于“页面查找/秒”和“页面读取/秒”计数器，并作为随时间的移动平均值进行计算。这是DBA最受欢迎的计数器之一，尽管它极具误导性。

一些数学：

90％的缓冲区高速缓存命中率表示10％的缓冲区高速缓存未命中。换句话说，我们可以说10％的请求进入磁盘。

加载的服务器每秒执行大约100,000至1,000,000次读取。因此，针对您的存储，10％的高速缓存未命中介于10,000到100,000 IOPS之间。

我的建议是您不要使用此计数器，而要使用 Buffer Manager:Page Reads/sec（“缓冲区管理器：页面读取数/秒”）计数器来查找有多少请求（以绝对值计）将要进入磁盘。

但是，如果您真的喜欢此计数器，则请始终寻找高于99.5％的值。这样，您将看到98％的缓冲区高速缓存命中率（BAD）；92％的人非常糟糕；85％为灾难。

通常，当服务器启动时，它处于预热过程中。在这种情况下，命中率计数器变得非常低。

 

【2.2】Average Disk Queue Length %Disk Busy

平均磁盘队列长度和磁盘繁忙百分比

磁盘队列计数器和磁盘使用百分比是最糟糕的性能指标。永远不要使用它。

• 没有最小值或最大值

人们谈论的是主轴数量的2倍，我们可以认为主轴是物理磁盘。但是，当今的SAN和虚拟化世界无法准确确定此数字。此外，已安装LUN的磁盘可以与其他LUN共享相同的磁盘阵列-无法确定此阈值是多少。

• 这些计数器提供许多误报。

所有高性能磁盘系统都执行磁盘排队以提高吞吐量。因此，比监视队列更重要的是测量存储延迟。排队是一个结果：当存储具有高磁盘延迟时，它将导致请求排队。

• 这些计数器没有实际意义。首先执行以下实验：收集此服务器信息，然后比较这些值。您会注意到，％磁盘繁忙和平均磁盘队列长度图表完全相同！我会说计算过程如下：
  • 平均磁盘队列长度（Average Disk Queue Length）= IOPS x延迟
  • 磁盘繁忙百分比（%Disk Busy）= IOPS x延迟x 100％

这位会计师的问题在于，没人知道这意味着什么。如果要与存储人员讨论队列，请谈论“未完成的I / O”而不是“平均磁盘队列长度”。

有趣的是，未完成的I / O（outstanding I/O）计量器具有非常相似的名称：“当前磁盘队列长度”（Current Disk Queue Length）。

 

 

 

参考转载文献

【0】：https://docs.microsoft.com/en-us/archive/blogs/fcatae/monitore-o-consumo-de-recursos-do-banco-de-dados

【1】：https://docs.microsoft.com/en-us/archive/blogs/fcatae/perfmon-falso-sentido-de-monitorao

标签：4.6,Perfmon,队列,计数器,探究,SQL,缓冲区,磁盘,高速缓存
来源： https://www.cnblogs.com/gered/p/12155247.html