您的位置:首页 > 编程学习 > 其它 > 正文

性能监视器中常用计数器

更多 时间:2014-12-11 类别:编程学习 浏览量:3216

性能监视器中常用计数器

性能监视器中常用计数器

一、打开 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申请的内存, 还是CLRmanaged heap, 都算在里面. Handle Count一样, 如果在整个程序周期内总体趋势连续向上, 说明有Memory Leak. 
  •  
  • Virtual Bytes
  • 该计数器记录了当前进程申请成功的用户态总内存地址, 包括DLL/EXE占用的地址和通过VirtualAlloc API进行的, Reserve了的内存地址数量, 所以该计数器应该总大于Private Bytes. 一般说来, Virtual BytesPrivate Bytes的变化大致一致. 由于内存分片的存在, Virtual BytesPrivate Bytes一般保持一个相对稳定的比例关系. Virtual BytesPrivate 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 BytesVirtual 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 heapnative memory的变化情况. 对于memory leak, 便于区分是managed heapleak, 还是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以内。
     
  •  
  • 标签:性能监视器