【监控实践】【3.6】基于Perfmon监控深入探究

【监控实践】【3.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】LogicalDisk: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）。

【2.3】Paging File:%Usage

分页文件：使用情况百分比

讨论了“分页文件”的最佳文件大小。有人说正确的做法是将分页文件设置为机器内存大小的1.5倍。但是，随着当今的计算机轻松达到128GB的RAM，那么该文件将拥有近200GB的磁盘空间。

1.5x RAM的口号有些过时了，应该适用于Windows NT和Windows2000。随着64位服务器的出现，现实已经发生了很大变化。今天我们可以说分页文件必须等于内核占用的大小，这将是生成故障转储所需的最小大小。

如何为Windows 64位版本确定适当的页面文件大小
https://support.microsoft.com/zh-cn/kb/2860880

如果分页文件的大小不取决于SQL Server，而是取决于内核，那么为什么要监视？

是的，您可以（临时）监视此计数器以确定最佳的页面文件值-根据机器内存的大小，该值可以在2GB到20GB之间。但可以肯定的是，此分页文件计数器对调整SQL Server毫无帮助。

最后，如果SQL Server使用的是分页文件，则很不对劲。数据库的目的是使用内存在磁盘上缓存数据。使用分页文件（磁盘）缓存数据（磁盘）根本没有任何意义。

【2.4】Memory: Page Faults/sec e Memory: Pages/sec

内存：页面错误/秒和内存：页面/秒

许多系统管理员使用这些计数器来确定服务器内存何时耗尽。RAM在Windows进程之间分配，并且在空闲时可以分页到分页文件。

在SQL Server上，其行为略有不同：当内存不足时，SQL Server将启动无内存进程，以防止将进程分页到磁盘。因此，想法是让SQL使用计算机上的所有可用内存来装载数据库缓存。如果操作系统（OS）需要内存，则标记SQL Server，并且其中的某些缓存已损坏，将可用内存返回给OS。因此，不必使用Page Faults / sec和Page Faults / sec计数器检查数据分页。

但是，有更充分的理由避免这些情况：
- Page Faults / sec（页面错误/秒） -也称为“软页面错误”，这些分页仅在重新定位内存时发生，而不必进入磁盘。
- 这是任何多任务操作系统中存在的常见过程。软页错误的发生与进程之间的上下文转换有关，而不是与内存不足有关。
因此，较高的Page Faults / sec值不对应于问题。
- Pages/sec（页数/秒） -被称为“硬页错误”，这些分页是内存和磁盘之间的数据移动。这比软页面错误要昂贵得多。分页文件的内存分页只是硬页面错误的可能原因之一。
- 实际上，任何“内存映射”引擎都算作数据移动操作。此计数器的问题是文件复制，读取和写入等简单操作会影响页面/秒。
当内存不足时，该计数器可能会略有增加。实际上，“ Memory：Pages / sec ”的高值通常是备份文件的写操作或使用文件资源管理器的文件复制。

假定SQL Server不使用分页文件，我不建议您执行OS分页监视。但是，如果您确实要诊断某种分页机制，则最好监视进程的工作集大小变化。

【2.5】SQL Access Methods: Page Splits/sec

SQL访问方法：页面拆分/秒

“页面拆分/秒”计数器指示服务器上出现的页面拆分次数。

　　记录存储在服务器上的8Kb页面中。当记录插入过程尝试输入新数据但在页面上找不到可用空间时，分页过程开始。在此过程中，一半的记录将移至新页面，以释放原始页面的空间。

　　分页过程完成后，涉及的页面将获得50％的可用空间，并可以继续进行插入过程。

通常，这是开始“填充因子”对话的首选计数器，因为高的页面拆分/秒计数器数字表示页面通常已满。但是，分页过程自然会在数据输入期间发生，并不一定与问题相对应。批量插入过程总是导致大量的页面拆分/秒。

如果您确实需要研究页面拆分，建议您使用sys.dm_db_index_operational_stats DMV。

但是，主要分析是使用sys.dm_db_index_physical_stats DMF（DBCC SHOWCONTIG的现代版本）验证碎片结果。

【2.6】SQL Locks: Lock Waits/sec

SQL锁定：锁定等待/秒

锁定等待/秒计数器指示每秒锁定多少会话。从理论上讲，使用Perfmon监视锁是一件有趣的事情。

例子：我在圣保罗的路上，突然开始下雨。我想使用类似于“锁定等待/秒”（Lock Waits/sec）的计数器来监控我被交通信号灯阻塞的频率。

实际上，这产生了奇怪的结果：

雨变得越来越大，我不走，我仍然无法越过大街。因此，“锁定等待/秒”（ Lock Waits/sec ）计数器指示为0，因为我没有经过任何其他信号量。

　　锁定等待/秒计数器没有提供有关服务器性能的许多线索。通常，该计数器的波动值很小。在麻烦或安静的条件下（完全相反的情况），它表示零。

几乎不可能看到Number of Deadlock / sec大于1。锁超时具有一个易记的名称，但是查询通常会超时（请注意，锁超时与@@ LOCK_TIMEOUT关联）。

我建议使用sys.dm_os_waiting_tasks和sys.dm_exec_requests DMV跟踪锁。但是，如果使用Perfmon监视锁确实很重要，请考虑使用“锁等待时间（ms）”和“平均等待时间（ms）”（“Lock Wait Time (ms)” ， “Average Wait Time (ms)”.）。

【2.7】SQL General Statistics: User Connections

SQL常规统计信息：用户连接

　　“用户连接”计数器告诉服务器连接了多少个会话。实际上，监视此计数器没有问题，因为服务器的最大连接数为30,000。当人们使用此计数器来测量服务器上的负载时，就会发生此问题。

例如，哪个服务器最过载？（相差50倍！）
- 具有100个连接的服务器A
- 具有5000个连接的服务器B
　　但是，负载取决于服务器上正在运行的命令。我可以想象一个名为DBA的用户，该用户能够运行一个DBCC CHECKDB命令，并且比同时运行的多个应用程序所造成的负载要大得多。

与用户连接非常相似的计数器称为“ SQL统计信息：批处理请求/秒”和“ SQLStatistics：SQL编译/秒”。编译和执行过程在很大程度上取决于所提交命令的类型。有些临时命令可以轻松地编译和执行。另一方面，有些命令会降低计算机性能。

正如我在Perfmon文章中所说的：对监视的错误感，请使用Performance Monitor创建服务器比较基准。连接数量是否已增加（批/秒），内部版本号？如果您想知道真正的原因，那么（暂时）放弃Perfmon并使用正确的策略（DMV或XE）。

【3】我应该监控哪些性能计数器？
```
Logical Disk        逻辑磁盘
    Avg Disk Sec/Read         平均磁盘秒数/读取
    Avg Disk Sec/Transfer     平均磁盘秒数/传输
    Avg Disk Sec/Write        平均磁盘秒数/写入
    Current Disk Queue Length        当前磁盘队列长度
    Disk Bytes/sec        　 磁盘字节/秒
    Disk Read Bytes/sec      磁盘读取字节/秒
    Disk Write Bytes/sec     磁盘写字节数/秒
    Disk Reads/sec           磁盘读取/秒
    Disk Transfers/sec       磁盘传输/秒
    Disk Writes/sec          磁盘写入/秒
    
Memory        内存
    %Committed Bytes In Use     使用的已提交字节百分比
    Available MB                可用MB
    Committed Bytes             提交的字节数
    Free System Page Table Entries        免费系统页表条目
    Pool Nonpaged Bytes       池非分页字节
    Pool Paged Bytes          池分页字节
    Network Interfaces        网络接口
    Bytes Received/sec        接收的字节数/秒
    Bytes Sent/sec            发送的字节数/秒
    Bytes Total/sec           总字节数/秒
    
Processor        处理器
    %Processor Time        　　  ％处理器时间
    %Privileged Time            特权时间百分比
    System                      系统名称
    Context Switches/sec        上下文切换/秒
    Exception Dispatches/sec    异常调度/秒
    Processor Queue Length      处理器队列长度
    System Calls/sec            系统调用/秒
        
--此外，对每个SQL实例使用以下计数器：
        
Buffer Manager              缓冲管理器
Database pages              数据库页面
Free list stalls/sec        空闲列表停顿/秒
Free pages                  免费页面
Lazy writes/sec             延迟写入/秒
Page life expectancy        页面寿命
Page lookups/sec            页面查找/秒
Page reads/sec              页面读取/秒
Readahead pages/sec         预读页数/秒
Stolen pages                页面被盗
Target pages                目标页面
Total pages                 总页数
General Statistics          一般统计
Connection Reset/sec        连接重置/秒
Logins/sec                  登录/秒
Logouts/sec                 登出/秒
User Connections            用户连接
SQL Statistics              SQL统计
Batch Requests/sec          批处理请求/秒
Safe Auto-Params/sec        安全自动参数/秒
Forced Parametrizations/sec 强制参数化/秒
SQL Compilations/sec        SQL编译/秒
SQL Re-Compilations/sec     SQL重新编译/秒
```
绩效基准

另外，性能监视器计数器对于随时间进行比较很重要。它们可能表明资源消耗或某些非正常活动的逐渐增加。以图形方式使用这些计数器可帮助识别某些不同的行为。

在两种情况下，Perfmon在其他工具（Profiler，DMV，XE）中脱颖而出：
- 分析SQL Server内存分配
- 存储响应时间测量
【4】案例分析

【4.1】Buffer Manager缓存与内存分析

数据缓冲区内存管理器（也称为数据缓存或数据库缓存）提供有关数据库内存利用率的最佳信息。

最初，我们分析计数器：
- 页面寿命（Page life expectancy）
- 延迟写入/秒（Lazy writes/sec）
- 空闲列表停顿/秒（Free list stalls/sec）
这是一些示例页面预期寿命（Page Life Expectancy：PLE）图表。特别是，如果PLE大于5000，而不是传统的极限值300，我喜欢使用validate。

在下面的情况下，所有服务器全天都加载，尽管显然只有第三个服务器内存不足。

　　

　　

　　

我们可以通过查看“空闲列表停顿/秒”计数器来补充分析，该计数器必须始终为绝对零-似乎有一个新的锁存器可以清楚地表明其干扰，称为“惰性编写器帮助器”。

然后，我们可以使用计数器查看内存分配：
- 数据库页面（Database pages）
- 空闲页面（Free pages）
- 页面被盗（Stolen pages）
- 目标页面（Target pages）
- 总页数（Total pages）
这些服务器具有：1）恒定和正态分布；2）内存不足和剩余；3）高消耗的非缓冲内存（被盗）。在所有图表中，都没有一种可以称为严重的情况，即被盗内存达到总内存的75％（内部压力）或总页数和目标页数随时间开始减少（外部压力）。。

　　

　　

　　

最后，我们确认PLE的变化是由服务器上使用“表读取/秒”和“预读页面/秒”计数器在服务器上进行表/索引扫描引起的。此外，您可以跟踪“页面查找/秒”计数器以了解负载情况。
- 页面查找/秒（Page lookups/sec）
- 页面读取/秒（Page reads/sec）
- 预读页数/秒（Readahead pages/sec）
下图如下：我们注意到读取的数量（随机+顺序）几乎等于预读（顺序）。因此，第一台服务器的使用率达到峰值，这会导致PLE的较大差异。在第二台和第三台服务器上，正在执行“扫描”操作，每秒读取10-3万页（相当于80-240MB /秒！！！）。

　　

　　

　　

在这里我们可以得出结论：
- 服务器1有足够的内存来处理负载。PLE差异是由于消耗高峰（请参阅预读图），但没有证据表明内存不足。
- 服务器2具有足够的内存（请参阅“空闲内存”图表），并且负载非常重（请参阅预读图表）。
- 服务器3收到与服务器2相似的负载（请参阅预读图），但是PLE表示内存水平一直很低。内存分配揭示了很多被保留为“被盗内存”（可能是“内存授权”）。该服务器上的负载很高，并且内存不足。
毫无疑问，性能监视器是进行SQL Server内存使用情况分析的最佳工具。

【4.2】监控存储分析

数据库的主要功能是存储，因为这是存储数据的地方。过去，存储是连接到服务器的SCSI磁盘。如今，磁盘已隐藏在虚拟化的多个层之后：
- SCSI / SAS / FC磁盘与磁盘阵列关联
- 磁盘阵列保持连接到磁盘控制器
- 磁盘控制器创建磁盘冗余（RAID1 / 5）
- 磁盘控制器允许您通过磁盘冗余创建逻辑磁盘（LUN）
- 逻辑磁盘（LUN）由存储前端管理
- 逻辑磁盘（LUN）具有写缓存，可加快小型随机写入
- 存储前端与光纤通道交换机连接
- 光纤通道交换机通过HBA连接到主机（服务器）
- 服务器（主机）将逻辑驱动器（LUN）挂载为本地磁盘
- 本地磁盘由分区管理器和卷管理器管理
- 本地磁盘接收Windows NTFS格式
- SQL Server在本地磁盘上创建MDF和LDF文件
因此，与存储进行通信的过程可能会遇到许多问题。确定问题原因的最简单方法是使用Performance Monitor进行监视。

只有3个步骤：
1. 我们根据IOPS计算存储负载
2. 我们计算与MB相关的存储负载
3. 我们计算存储响应时间
首先，我们看一下服务器对存储施加的IOPS数量：
- 磁盘读取/秒（Disk Reads/sec）
- 磁盘写入/秒（Disk Writes/sec）
- 磁盘传输/秒（Disk Transfers/sec (对应于读取和写入)）
这是速率范围为1000-2000 IOPS的服务器的示例。作为参考，单个SCSI磁盘可以执行大约150 IOPS。因此，此负载相当于7到13个SCSI磁盘。

　　

然后，我们测量吞吐量。我们注意到速率约为100MB / s。作为参考，一个2Gbit HBA可以传输大约200MB / s。

　　

最后，我们测量了存储响应时间，发现时间超过了100ms。此外，我们可以将其与出色的I / O进行比较，后者显示了HBA中的排队。作为参考，SCSI磁盘的使用寿命通常为5毫秒，而SSD磁盘的延迟仅为0.1毫秒。

　　

分析：我们注意到响应时间与常规磁盘时间（5毫秒）不兼容。我们建议该存储的性能至少为10个专用LUN SCSI磁盘。

重载服务器

让我们转到第二个示例。这次，我将所有内容放在同一张图表上以分析负载：
- IOPS：范围从2000到6000，峰值达到10000
- 带宽：平均200MB / s，峰值为400、1000和1600MB / s
　　

评论：我们正在应对存储的高负荷。
- 10000 IOPS实际上是专用的服务器存储
- 1000MB / s足以造成8Gbit HBA瓶颈
- 1000MB / s通常需要专用的FC交换机
响应时间：10ms以下，大约20ms左右有变化。添加磁盘队列后，我们看到队列快速增长。

　　

分析：磁盘响应时间非常好。负载极高（实际上是专用存储），响应时间为10毫秒。排队不应被视为问题。

低负载服务器的日志磁盘

我们首先查看与IOPS负载和传输（MB / s）相关的计数器。在这里，我们的负载几乎为零，小于50 IOPS，小于10 MB / s。作为参考，我们可以使用执行150 IOPS的SCSI磁盘和发送200 MB / s的光纤通道。

　　

作为响应时间，让我们只看写延迟。为此，我们将图形设置为0到20毫秒。我们观察到延迟在2到15毫秒之间急剧变化。

　　

分析：此日志磁盘的写入速率非常低。但是，这确实表明由于延迟时间的突然变化而导致存储瓶颈。如果性能足够，则延迟几乎是恒定的。尽管对当前系统没有影响，但是当系统负载增加时，此问题可能会显现出来。

由于此问题会影响日志磁盘LUN（小而连续的写入），因此负载应由存储前端缓存吸收。因此，时间的突然变化表明Windows Volume Manager，Switch FC或Storage Frontend中存在瓶颈。

经过调查，我们确定存储前端存在问题（扇出比率），这意味着前端端口过载了非常多的主机。解决方案是在其他存储端口之间重新平衡主机。

结论

Performance Monitor是分析存储响应时间的最佳工具，它使您能够确定系统负载（IOPS和MB / s）并测量响应时间

【5】监控清单：服务器性能（windows）

从Windows的角度来看，基础结构分析分为其核心功能：CPU，内存，存储和网络。

【5.1】CUP

监视服务器上的CPU消耗。
- Processor：％Processor Time：检查CPU消耗是否低于80％。保持10-20％的裕度以允许任何峰值使用非常重要。
- Processor： %Privileged Time：特权时间百分比：验证内核时间消耗是否低于30％。对于数据库服务器而言，将更多的时间花在内核上运行系统任务而不是运行SQL查询没有任何意义。
- System: Processor Queue Length：处理器队列长度：随时间监视此值，并与CPU消耗进行比较。与处理器队列关联的高CPU消耗量表明存在影响SQL Server性能的外部进程。
【5.2】memory

监视可用的OS内存和内部内核消耗。
- Memory: Available MB：可用MB：随着时间的推移监视此计数器，并确保其始终大于100MB。如果某个时间该指示器过低，建议设置或降低SQL Server服务器的“最大服务器内存”，并确保内存始终可用。
- Memory: Pool Nonpaged Bytes:：池未分页的字节数：分析几天内未分页池的数量是否保持恒定，或者是否有内存泄漏的迹象。这可能表明内核驱动程序存在问题，并影响操作系统稳定性。
- Memory: Pool Paged Bytes：分页缓冲池字节数：分析这些天中分页缓冲池的数量是否保持恒定，或者是否有内存泄漏的迹象。这可能表明内核驱动程序存在问题，并影响操作系统稳定性。
【5.3】Storage

【4.2】中详细介绍了存储分析。理想情况下，按磁盘容量进行个性化分析，而不要合并为单个分析。

可以用IOPS衡量负载。较高的IOPS值会导致FC，SCSI，SAS，SATA机械磁盘瓶颈。
- Disk Reads/sec：磁盘读取数/秒：计算数据磁盘上的读取数。从理论上讲，这些读数具有8Kb的随机和阻塞特征。但是，通常会发现执行表扫描并导致顺序读取和大于8Kb的块的服务器。因此，可以通过写入块的大小（磁盘字节/读取计数器）来确定读取的性质（随机或顺序）。参考值：
  - 100 IOPS = 7200 RPM磁盘
  - 150 IOPS = 10k RPM磁盘
  - 175 IOPS = 15k RPM磁盘
  - 10,000 IOPS = SSD磁盘
- Disk Writes/sec：磁盘写入数/秒：忽略对数据磁盘的写入次数。忽略tempdb磁盘上的此计数器：日志和数据。计算日志磁盘上的IOPS。理想情况下，该值应低于200，尽管可以接受高达1000 IOPS。通常，通过存储中的写缓存来加速写操作。
- Disk Transfers/sec：磁盘传输/秒：读写IOPS的总和。当您需要简化的负载分析时，请使用此计数器。
负载可以MB / s为单位。高吞吐量值导致磁盘接口和互连电缆出现瓶颈
- Disk Read Bytes/sec：磁盘读取字节/秒：计算读取吞吐量。此值没有限制。建议
  - 20 MB /秒：低
  - 100 MB /秒：正常
  - 200 MB / s：高（相当于2Gbit光纤通道）
- Disk Write Bytes/sec：磁盘写字节数/秒：计算写传输速率。但是，有一些注意事项：
  - 数据磁盘：写流是由检查点过程引起的，它可以增加写并发性，并间接影响存储延迟。
  - 日志磁盘：由于数据包很小，写入速率几乎总是很低（低于20MB / s）
- Disk Bytes/sec：磁盘字节数/秒：读写吞吐量之和。当您需要简化的负载分析时，请使用此计数器。
磁盘延迟是存储的主要指标：
- Avg Disk Sec/Read：平均磁盘秒数/读取：验证磁盘延迟是否在预期范围内。通常，将最大值50到100ms用作数据磁盘的响应时间。时间的建议：
  - <1ms：令人难以置信
  - <3ms：极好
  - <5ms：很好
  - <10ms：如预期
  - <20ms：合理
  - <50ms：限制
  - > 100ms：不好
  - > 1秒：严重的磁盘容纳
  - > 15秒：严重的存储问题
- Avg Disk Sec/Write：平均磁盘秒数/写入：验证磁盘延迟是否在预期范围内。忽略数据磁盘的该值。将此计数器用于低延迟日志磁盘：
  - <1ms：出色
  - <3ms：好
  - <5ms：合理
  - <10ms：限制
  - > 20ms：不好
  - > 1秒：严重的磁盘容纳
  - > 15秒：严重的存储问题
- Avg Disk Sec/Transfer：平均磁盘秒数/传输：读写时间之间的加权平均值。需要简化分析而不必同时查看两个计数器（读和写）时，请使用此计数器。
另外，可能包括未完成的I / O计数器。
- Current Disk Queue Length：当前磁盘队列长度：对应于等待来自存储的响应或在HBA中排队的活动中的I / O请求的数量。不幸的是，此计数器与“ Avg Disk Queue Length”含义不一。如果等待时间足够，则可以调整HBA卡的“队列深度”参数。这样，主机可以增加发送到存储的I / O数量并缩小HBA队列。这是电路板特定的参数（例如Emulex，QLogic等）。
【5.4】network

网络流量监控。
- Bytes Received/sec：接收的字节数/秒：计算网络接收的数据速率。该值始终较低，因为它与带有命令的软件包相对应。例外是在接收BCP负载期间。参考值：
  - 5MB /秒：正常
  - 10MB / s：高
  - 100MB / s：非常高（相当于1Gbit以太网卡）
- Bytes Sent/sec：发送的字节数/秒：计算通过网络发送的数据速率。此值大于接收到的数据量，因为它对应于要返回给客户的数据集。
  - 10MB / s：正常
  - 20MB / s：高
  - 100MB / s：非常高（相当于1Gbit以太网卡）
- Bytes Total/sec：总字节数/秒：通过网络接收和发送的数据总和。当您需要简化网络流量分析时，请使用此计数器。
【6】监控清单：服务器性能（SQL）

SQL Server基准

这些计数器应用于帮助表征数据库的负载：

【6.1】常规统计
- （Connection Reset/sec）连接重置/秒：通过连接池重新启动会话速率的会话
- （Logins/sec）登录/秒：服务器认证率
- （Logouts/sec）注销/秒：用户与服务器断开连接的速率
- （User Connections）用户连接数：用户会话数
SQL统计
- （Batch Requests/sec）批处理请求/秒：每秒接收的请求速率
- （Safe Auto-Params/sec）安全自动参数/秒：执行自动参数化（自动参数）
- （Forced Parametrizations/sec）强制参数化/秒：执行强制参数速率
- （SQL Compilations/sec）SQL编译/秒：优化程序的生成速度
- （SQL Re-Compilations/sec）SQL重新编译/秒：优化程序重新编译率
这些计数器有一些价值和建议。但是，最重要的是要有一个基准以便将来进行比较。

【6.2】（Buffer Manager）缓冲区管理器：内存消耗

借助计数器，可以更好地观察SQL Server服务器的内存：
- 缓冲区管理器：（Page life expectancy）页面预期寿命：验证该值保持恒定或随时间增加。在NUMA机器上，页面预期寿命的计算更为复杂，并且对应于节点之间的谐波平均值。该计数器的下降表示负载增加的时刻。参考值：
  - <10：过低，可能会产生错误，断言和转储
  - <300：低
  - 1000：合理
  - 5000：好
- 缓冲区管理器：（Free list stalls/sec）空闲列表停顿/秒：确保其始终为零。停顿意味着线程已被冻结，并且都与Lazy Writer一起工作以释放内存。当“页面预期寿命”接近零时，通常会发生此行为。
- 缓冲区管理器：（Lazy writes/sec）延迟写入/秒：使用此数字作为基准。惰性编写器（LW）进程在后台缓慢发生。当此计数器增加时，可能意味着可用内存不足，因此服务器加速了LW进程。
- 缓冲区管理器：（Page lookups/sec）页面查找/秒：使用此数字作为基准。
- 缓冲区管理器：（Page reads/sec）页面读取数/秒：使用此数字作为与读取IOPS操作进行比较的基准。我们可以估计每个页面读取对应于磁盘上的读取I / O。
- 缓冲区管理器：（Readahead pages/sec）预读页数/秒：使用此数字作为比较磁盘读取速率（MB / s）的基准。我们可以说每个Readahead页面对应于磁盘上顺序读取的8Kb。
【6.3】SQL Server内存分配

可以通过计数器观察数据库高速缓存的内存分配：
- （Database pages）数据库页面：与数据库高速缓存对应的页面数。
- （Free pages）可用页数：缓冲池中的可用页数。如果可用页数是恒定的（超过1000个），则将剩余内存。
- （Stolen pages）被盗页面：专用于内部数据库任务（编译，执行，对象缓存）的页面数。被盗页面的数量越多，可用于数据库高速缓存的页面就越少。建议值：
  - 25％：正常
  - 50％：相对较高，可能导致内部内存不足-除非有许多可用页。
  - 75％：太高了，请调查哪个Memory Clerk负责消耗-除非可用的可用页面太多
- （Target pages）目标页数：SQL Server将来要访问的总页数。监视此值的突然下降，这将指示外部存储器压力。
- （Total pages）总页数：SQL Server分配的总页数。
  - 目标页面=总页面：正常
  - 目标页>总页数：服务器预热或内存不足
  - 目标页面<总页面数：只要满足此条件，Lazy Writer就会积极努力减少页面数，直到匹配目标页面为止。
参考转载文献

【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

【2】perfmon 3 parts：

　　【2.1-2.2】https://docs.microsoft.com/en-us/archive/blogs/fcatae/os-7-grandes-mitos-do-perfmon-parte-1

　　【2.3-2.4】https://docs.microsoft.com/en-us/archive/blogs/fcatae/os-7-grandes-mitos-do-perfmon-parte-2

　　【2.5-2.7】https://docs.microsoft.com/en-us/archive/blogs/fcatae/os-7-grandes-mitos-do-perfmon-parte-3

【3】：https://docs.microsoft.com/en-us/archive/blogs/fcatae/contadores-do-perfmon

【4】：

　　【4.1】https://docs.microsoft.com/en-us/archive/blogs/fcatae/perfmon-monitorando-o-buffer-manager

　　【4.2】https://docs.microsoft.com/en-us/archive/blogs/fcatae/perfmon-monitorando-o-storage
文章： Perfmon-监测虚假的安全感

7大Perfmon神话性能指标：
文章：计数器性能监视器

挑战：使用Perfmon分析服务器

用Perfmon监视
- Perfmon：监视缓冲区管理器
- Perfmon：监视存储
检查清单
- 清单：服务器性能（Windows）
- 清单：服务器性能（SQL）
相关阅读:
千里之行，始于足下
 Asp.Net构架(Http请求处理流程)
c# MVC5（二） MVC与IOC结合
 c# MVC5（一）初步认识以及新建mvc
使用C#创建Windows服务
 Cron Expressions——Cron 表达式（QuartZ调度时间配置）
定时调度之Quartz
ORM之EF初识
 Redis原理及使用
 为什么使用 Redis 及其产品定位
原文地址：https://www.cnblogs.com/gered/p/12155247.html

【监控实践】【3.6】基于Perfmon监控深入探究

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

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

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

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

【2】perfmon的七大被神话的性能指标

【2.1】Buffer Manager:Buffer Cache Hit Ratio

【2.2】LogicalDisk:Average Disk Queue Length %Disk Busy

【2.3】Paging File:%Usage

【2.4】Memory: Page Faults/sec e Memory: Pages/sec

【2.5】SQL Access Methods: Page Splits/sec

【2.6】SQL Locks: Lock Waits/sec

【2.7】SQL General Statistics: User Connections

【3】我应该监控哪些性能计数器？

绩效基准

【4】案例分析

【4.1】Buffer Manager缓存与内存分析

【4.2】监控存储分析

【5】监控清单：服务器性能（windows）

【5.1】CUP

【5.2】memory

【5.3】Storage

【5.4】network

【6】监控清单：服务器性能（SQL）

SQL Server基准

【6.1】常规统计

【6.2】（Buffer Manager）缓冲区管理器：内存消耗

【6.3】SQL Server内存分配

参考转载文献