标签：4.6 Perfmon 队列 计数器 探究 SQL 缓冲区 磁盘 高速缓存
【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】一时的指标代表性能不好嘛？错误的
所以我可以得出一些（错误的）结论：
- CPU消耗相对较高，约为65％，这可能表明处理器太忙
- 磁盘队列大于2。这可能表示严重的磁盘问题。
- 预期页面寿命（PLE）计数器低于300，表明内存不足。
- 缓冲区高速缓存命中率超过90％，表明内存不足不会影响系统
- 登录的用户数量很多（5200），可能会导致系统负载。
这些只是基于观察值的假设。这些孤立的事实可以回答以下问题：我是否需要购买更多的CPU？我应该向数据库添加内存吗？登录的用户过多吗？您会建议使用SSD磁盘吗？
实际上不该基于此来做任何操作，应当以图表为例：
【1.2】应该忘记数字，使用图表
分析冷数字很困难，因此只要有可能就使用图表。该图显示了指标的波动以及已更改的日期/时间。请参见“页面预期寿命”会计师的下表。在这种情况下，我们得出什么结论？
看来在上午10点，我们的使代价最小最低。
注意，分析仍然很困难。我可以提出两个有效但矛盾的说法：
- 太好了！服务器运行良好。
- 这样的服务器可以受益于增加的内存。
这里的一切都取决于比较的基础。如果我们将其与高负载服务器进行比较，可以说该服务器看起来不错（＃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）。
参考转载文献
【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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。