性能监视器中常用计数器

性能监视器中常用计数器

性能监视器中常用计数器

一、打开 Windows 性能监视器

 

方式1、点击“开始”-“控制面板”-“管理工具”-“性能监视器”

方式2、点击“开始”-在搜索框中输入“perfmon.msc”回车

 

 

 

二、性能监视器中常用计数器

 

 

1、Process object

 

Process object中的计数器可以根据目标进程分析内存, CPU, 线程数目和handle数目. 选出问题的目标进程, 然后分析目标进程的下面一些计数器.

 

%Processor Time

该计数器是该进程占用CPU资源的指标. 即便进程繁忙的时候, CPU平均占用率应该在80%以内. 如果超过该数值, 可以认为程序发生了高CPU的问题. 另外一种问题是CPU波动幅度大. 虽然平均占用率不高, 但是上下跳动频繁. 在某一个短时间段里面, 会有连续高CPU的情况出现.

 

Handle Count

该计数器记录了当前进程使用的kernel object handle数量. Kernel object是重要的系统资源. 当程序进入稳定运行状态的时候, Handle Count数量也应该维持在一个稳定的区间. 如果发现Handle Count在整个程序周期内总体趋势连续向上, 应该考虑程序是否有Handle Leak.

 

ID Process

该计数器记录了目标进程的进程ID. 你可能觉得奇怪, ID有什么好观察的? 进程ID是用来观察程序是否有重启发生. 比如ASP.NET工作进程可能会自动回收. 由于进程名都相同, 所以只有通过进程ID来判断是否有重新启动现象. 如果ID有变化, 那么而看看程序是否发生崩溃或者Recycle. 

 

% User Time

是系统非核心操作消耗的CPU时间，如果是数据库服务器的话，%User Time 值大的原因很可能是数据库的排序或是函数操作消耗了过多的CPU时间，此时可以考虑对数据库系统进行优化。

 

Private Bytes 

该计数器记录了当前通过VirtualAlloc API进行的, Commit了的Memory数量. 无论是直接调用API申请的内存, Heap Manager申请的内存, 还是CLR的managed heap, 都算在里面. 跟Handle Count一样, 如果在整个程序周期内总体趋势连续向上, 说明有Memory Leak. 

 

Virtual Bytes

该计数器记录了当前进程申请成功的用户态总内存地址, 包括DLL/EXE占用的地址和通过VirtualAlloc API进行的, Reserve了的内存地址数量, 所以该计数器应该总大于Private Bytes. 一般说来, Virtual Bytes与Private Bytes的变化大致一致. 由于内存分片的存在, Virtual Bytes与Private Bytes一般保持一个相对稳定的比例关系. 当Virtual Bytes与Private Bytes的比例大于2的时候, 程序往往有比较严重的内存地址分片. 

 

 

2、Processor object

 

Processor object记录系统中芯片的负载情况. 由于普通程序并不可以绑定到某个具体的CPU上执行, 所以在多CPU机器上观察Total Instance也就足够了. 

 

%Processor Time 

该计数器跟Process下的%Processor Time的意义一样, 不过这里记录的不是针对具体的某一个进程, 而是整个系统. 通过把该计数器跟Process下的同名计数器一起比较, 就能看出系统的高CPU问题是否是由于单一的某个进程导致的. 

 

 

3、Memory Object

Memory object记录了当前系统中整体内存的统计信息. 

 

Avaiable Mbytes 和 Committed Bytes

---------------------

Available Mbytes记录了当前剩余的物理内存数量. Committed Bytes记录了所有进程commit的内存数量. 结合两个计数器可以观察到:

(1)、两者相加可以粗略估计系统总体可用内存的多少, 便于估计物理配置.

(2)、当Available Mbytes少于100MB的时候, 说明系统总体内存紧张, 会影响到系统所有进程的性能. 应该考虑增加物理内存或检查内存泄露.

(3)、通过比较Process object中的Private Bytes和Virtual Bytes, 便于进一步确认是否有内存泄露, 判断内存泄露是否是由某一单个进程导致的

Free System Page Table Entries, Pool Paged Bytes 和 Pool Nonpaged Bytes

这三个计数器可以衡量核心态空闲内存的数量. 特别是当使用/3GB开关后, 核心态内存地址被压缩, 容易导致核心态内存不足, 继而引发一些非常奇怪的问题.

 

Pages/sec
这个计数器记录的是每秒钟内存和磁盘之间交换的页面数。交换更多的页面、超过你服务器承受的更多的I/O，将轮流降低你SQLserver的性能。你的目的就是尽量将页面减少到最小，而不是消除它。

如果你的服务器上SQLServer是最主要的应用程序，那么这个值的理想范围是0～20之间。可能很多时候你看到的值都会超过20。这个值一般要保持在每秒的平均页数在20以下。

如果这个值平均总是超过20，其中最大的一个可能是内存瓶颈问题，需要增加内存。通常来说，更多的内存意味着需要执行的页面更少。
在大多数情况下，服务器决定SQLServer使用的适当内存的大小，页面将平均小于20。给SQLServer适当的内存意味着服务器的缓存命中率（Buffer Hit Cache Ratio 这个稍后会讲到）达到99％或者更高。如果在一个24小时的周期里你的sqlserver的缓存命中率达到99％或者更高，但是在这个期间你的页面数总是超过20，这意味着你或许运行了其他的程序。如果是这样的情况，建议你移除这些程序，使SQLServer是你的服务器的最主要的程序。

如果你的sqlserver服务器没有运行其他程序，并且在一个24小时的周期里页面数总是超过20，这说明你应该修改你对SQLServer的内存设置了。将其设置为“动态配置SQLServer的内存”，并且最大内存设置得高一些。为了达到最优，SQLServer将尽可能的获得多的内存以完成自己的工作，而不是去和其他的程序争夺内存。
 

Available Bytes
另一个检查SQLServer是否有足够的物理内存的方法是检查Memory Object: Available Bytes计数器。 这个值至少大于5M，否则需要添加更多的物理内存。在一个专门的SQLServer服务器上，SQLServer试图维持4-10M的自由物理内存，其余的物理内存被操作系统和SQLServer使用。当可用的物理内存接近5M或者更低时，SQLServer最可能因为缺少内存而遇到性能瓶颈。遇此情况，你需要增加物理内存以减少服务器的负荷，或者给SQLServer配置一个合适的内存。
 

4、.NET CLR Memory object

.NET CLR Memory object记录了CLR进程中跟CLR相关的内存信息. 该类别下的所有计数器都很有趣, 意思也非常直接. 建议用一个例子程序进行测试和研究. 下面是两个最常用的计数器.

#Bytes in all heaps

Bytes in all heaps 记录了上次GC发生时所统计到的, 进程中不能被回收的所有CLR object占用的内存空间. 该计数器不是实时的, 每次GC发生的时候, 该计数器才更新. 与同一进程的Process下的Private Bytes比较, 可以区分出managed heap和native memory的变化情况. 对于memory leak, 便于区分是managed heap的leak, 还是native memory 的leak.

%Time in GC

%Time in GC记录了GC发生的频繁程度. 一般来说15%以内算比较正常. 当超过20%时, 说明GC发生过于频繁. 由于GC不仅带来很高的CPU开销, 而且还需要挂起目标进程的CLR线程, 所以高频率GC是非常危险的. 通过跟CPU利用率和其他性能指标的比较, 往往能够看出GC对性能的影响. 高频率的GC往往因为:

(1)、负载过高.

(2)、不合理的架构, 对内存使用率不高.

(3)、内存泄露, 内存碎片导致内存压力.

 

5、System object

System object记录系统中一个整体的统计信息. 所以不区分instance. 通过比较System object下的counter和其他counter的变化趋势, 往往能看出一些线索.

Context Switch/ sec

Context Switch标示了系统中整体线程的调度, 切换频率. 线程切换是开销比较大的操作. 频繁的线程切换回导致大量CPU周期被浪费. 所以当看到高CPU的时候, 一定要与Context Switch一起比较. 如果两者有相同的变化趋势, 高CPU往往是由于contention(线路争夺)导致的, 而不是死循环.

Exception Dispatches/ sec

Exception Dispatches表示了系统中异常派发, 处理的频繁程度. 跟线程切换一样, 异常处理也需要大量的CPU开销. 分析方法跟Context Swith雷同. 

File Data Operations/ sec 

File Data Operations记录了当前系统中磁盘文件读写的频繁程度. 通过观察该计数器跟其他性能指针的变化趋势, 能够判断磁盘文件操作是否是性能瓶颈. 类似的计数器还有Network Interface, Bytes Total/ sec 

 

6、ASP.NET Applications（ASP.NET 应用程序）

 

Requests/ Sec（每秒的请求数）

允许您检验请求的处理速度是否于发送速度相适应。如果每秒请求数的数值低于每秒产生的请求数，则会出现排队现象。这通常意味着已经超过了最大请求速度。

 

Errors Total（总错误数）

在执行 HTTP 请求期间发生的错误总数。包括任何分析器、编译或运行时错误。此计数器是"Errors During Compilation"（编译错误数）、"Errors During Preprocessing"（预处理错误数）和"Errors During Execution"（执行错误数）计数器的总和。运转正常的 Web 服务器不应产生任何错误。如果错误发生在 ASP.NET Web 应用程序中，它们的存在可能会让实际的吞吐量结果产生偏差。

 

 

7、ASP.NET 性能监视器

 

Request Execution Time（请求执行时间）

显示了呈现所请求页面并将其传送给用户所需的时间（以毫秒计）。跟踪此计数器通常要比跟踪页面呈现时间效果更好。此计数器可以更全面地衡量从开始到结束的整个请求时间。在与基准进行对比时，如果此计数器的平均值较低，则说明应用程序的伸缩性和性能均得到了改善。

 

Application Restarts（应用程序重新启动）

应用程序在 Web 服务器生存期间发生重新启动的次数。每次发生 Application_OnEnd 事件时，应用程序的重新启动次数都会增加。应用程序进行重新启动的原因可能是：更改了 Web.config 文件、更改了存储在应用程序的 \bin 目录下的程序集、或者 Web Forms 页面中发生了太多的更改。如果此计数器的值出现意料之外的增加，说明某些不可预知的问题导致 Web 应用程序被关闭。在这种情况下，应该认真调查问题原因。

 

Requests Queued（排队的请求数）

在队列中等待服务的请求数。如果此数字随着客户端负载的增加而呈现线性的增长，则说明 Web 服务器计算机已经达到了它能够处理的并发请求极限。此计数器的默认最大值为 5,000。您可以在计算机的 Machine.config 文件中更改此设置。

 

Worker Process Restarts（工作进程重新启动）

工作进程在服务器计算机上重新启动的次数。如果出现意料之外的故障或者被有意回收，则工作进程会重新启动。如果此计数器的值出现意料之外的增加，应认真调查问题原因。

 

 

8、Physical Disk

 

% Disk Time 
 这个计数器度量磁盘阵列繁忙程度（不是逻辑分区或磁盘阵列上独立的磁盘）。它提供一个对磁盘阵列繁忙程度相对较好的度量。原则上计数器% Disk Time的值应该小于55%。如果持续超过55%（在你24小时的监控周期里大约超过10分钟），说明你的SQLServer有I/O瓶颈。如果你只是偶尔看到，也不必太担心。但是，如果经常发生的话（也就是说，一个小时出现好几次），就应该着手寻找增加服务器I/O性能或者减少服务器负荷的解决之道了。一般是为磁盘阵列增加磁盘，或者更好更快的磁盘，或者给控制器卡增加缓存，或者使用不同版本的RAID，或者更换更快的控制器。
 

Avg. Disk Queue Length

除了观察物理磁盘的% Disk Time计数器外，还可以用Avg. Disk Queue Length计数器。磁盘阵列中的各个磁盘的该值如果超过2（在你24小时的监控周期里大约超过10分钟），那么你的磁盘阵列存在I/O瓶颈问题。象计数器% Disk Time一样，如果只是偶尔看到，也不必太担心。但是，如果经常发生的话，就应该着手寻找增加服务器I/O性能的解决之道了。如前所述。

你需要计算这个值，因为性能监视器不知道你的磁盘阵列中有多少物理磁盘。例如，如果你有一个6个物理磁盘组成的磁盘阵列，它的Avg. Disk Queue Length值为10，那么实际每个磁盘的值为1.66（10/6＝1.66），它们都在建议值2以内。