【转】一些重要的计数器
2011-09-07 18:15
246 查看
些重要的计数器
解决性能问题的时候,我往往会让客户添加下面一些计数器进行性能收集。
Process object下的所有计数器。
Processor object下的所有计数器
System object下的所有计数器
Memory object下的所有计数器
如果客户的程序是.NET程序,还会添加 .NET 开头的object下的所有技术其
如果客户使用ASP.NET,还会添加 ASP.NET 开头的object下的所有技术其
分析性能日志的时候,我会重点观察下面这些计数器
Process object
Process object中的计数器可以针对目标进程分析内存,CPU,线程数目和handle数目。首先要确定目标进程,然后分析目标进程的下面一些计数器:
% Processor Time
该计数器是该进程占用CPU资源的指标。当进程繁忙的时候,CPU平均占用率应该在80%以内。如果超过该数值,程序可以认为发生了high 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
Private Bytes
该计数器记录了当前通过VirtualAlloc API Commit的Memory数量。无论是直接调用API申请的内存,被Heap Manager申请的内存,或者是CLR 的managed heap,都算在里面。跟Handle Count一样,如果在整个程序周期内总体趋势是连续向上,说明有Memory Leak
Virtual Bytes
该计数器记录了当前进程申请成功的用户态总内存地址,包括DLL/EXE占用的地址和通过VirtualAlloc API Reserve的Memory Space数量,所以该计数器应该总大于Private Bytes。一般来说,Virtual Bytes跟Private Bytes的变化大致一致。由于内存分片的存在, Virtual Bytes跟Private Byes一般保持一个相对稳定的比例关系。当Virtual Bytes跟Private Bytes的比例关系大于2的时候,程序往往有比较严重的内存地址分片。
Processor object
Processor object记录系统中芯片的负载情况。由于普通程序并不刻意邦定到某个具体CPU上执行,所以在多CPU机器上观察Total Instance也就足够了
% Processor Time 该计数器跟Process下的% Processor Time的意义一样,不过这里记录的是所有进程带来的芯片,而不是针对具体某一个进程。通过把这个计数器跟Process下的同名计数器一起比较,就能看出系统的高CPU问题是否是由于单一的某个进程导致的
System
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 Switch雷同。
File Data Operations/sec
File Data Operations记录了当前系统中磁盘文件读写的频繁程度。通过观察该计数器跟其他性能指标的变化趋势,通常能够判断磁盘文件操作是否是性能瓶颈。类似的计数器还有Network Interface\Bytes total/sec
Memory
Memory object记录了当前系统中整体内存的统计信息。
Available Mbytes
Committed Bytes
Available Mbytes记录了当前剩余的物理内存数量。Committed Bytes记录了所有进程commit的内存数量。结合两个计数器可以观察到:
1) 两者相加可以粗略估计系统总体可用内存多少,便于估计物理配置
2) 当Available Mbytes少于100MB的时候,说明系统总体内存吃紧,会影响到整个系统所有进程的性能。应该考虑增加物理内存或者监察内存泄露
3) 通过比较Process\Private Bytes跟Virtual Bytes,便于进一步确认是否有内存泄露,判断内存泄露是否是某一单个进程导致
Free System Page Table Entries,Pool Paged Bytes和Pool Paged Bytes
这三个计数器可以衡量核心态空闲内存的数量。特别是当使用/3GB开关后,核心态内存地址被压缩,容易导致核心态内存不足,继而引发一些非常妖怪的问题。可以参考前面提到的文章:
How to use the /userva switch with the /3GB switch to tune the User-mode space to a value between 2 GB and 3 GB
http://support.microsoft.com/kb/316739/en-us
.NET CLR Memory
.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) 内存泄露,内存分片导致内存压力
如果目标程序是ASP.NET,在ASP.NET开头的object中,下面这些计数器对于测量ASP.NET的性能非常有用。由于不少计数器存在于多个object类别中,下面只列出具体的计数器名字,而不去对应到具体的object:
Application Restarts
Application Restarts记录了ASP.NET Application Domain重启的次数。导致ASP.NET appDomain重启的原因往往是虚拟目录中被修改。比如修改了web.config文件,或者防毒程序对虚拟目录进行扫描。通过该计数器可以观察是否有异常的重启现象
Request Execution time
Request Execution time记录了请求的执行时间,是衡量ASP.NET性能的最直接参数。通过该计数器的平均值来衡量性能是否合乎预期值。需要注意的地方是由于Windows并非实时系统,所以不能用峰值来衡量整体性能。比如当GC发生的时候,请求执行时间肯定都要超过GC的时间。所以平均值才是有效的标准
Request Current
Request Current记录了当前正在处理的和等待处理的请求。最理想的情况是Request Current等于CPU的数量,这说明请求跟硬件资源能并发处理的能力恰好吻合,硬件投资正运行在最优状态。但是一般说来,当负荷比较大的时候,Request Current也随着增高。如果Request Current在一段时间内有超过10的情况,说明性能有问题。注意观察这个时候对应的CPU情况和其他的资源。如果CPU不高,很可能是程序中有blocking发生,比如等待数据库请求,导致请求无法及时完成。
Request/second
Request/second计数器记录了每秒钟到达ASP.NET的请求数。这是衡量ASP.NET负载的直接参数。注意观察Request/second是否超过程序的预期吞吐量。如果Request/Second有突发的波动,注意看是否有拒绝服务攻击。通过把Request/second,Request Current, Request Execution time和系统资源一起比较,往往能够看出来ASP.NET整体性能的变化和各个因素之间的影响
Request in Application Queue
当ASP.NET没有空余的工作线程来处理新进入的请求的时候,新的请求会被放到Application Queue中。当Application Queue堆积的请求也超过设定数值的时候,ASP.NET直接返回503 Server too busy错误,同时丢弃该请求。所以正常情况下,Request in Application Queue应该总为0,否则说明已经有请求堆积,性能问题严重
解决性能问题的时候,我往往会让客户添加下面一些计数器进行性能收集。
Process object下的所有计数器。
Processor object下的所有计数器
System object下的所有计数器
Memory object下的所有计数器
如果客户的程序是.NET程序,还会添加 .NET 开头的object下的所有技术其
如果客户使用ASP.NET,还会添加 ASP.NET 开头的object下的所有技术其
分析性能日志的时候,我会重点观察下面这些计数器
Process object
Process object中的计数器可以针对目标进程分析内存,CPU,线程数目和handle数目。首先要确定目标进程,然后分析目标进程的下面一些计数器:
% Processor Time
该计数器是该进程占用CPU资源的指标。当进程繁忙的时候,CPU平均占用率应该在80%以内。如果超过该数值,程序可以认为发生了high 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
Private Bytes
该计数器记录了当前通过VirtualAlloc API Commit的Memory数量。无论是直接调用API申请的内存,被Heap Manager申请的内存,或者是CLR 的managed heap,都算在里面。跟Handle Count一样,如果在整个程序周期内总体趋势是连续向上,说明有Memory Leak
Virtual Bytes
该计数器记录了当前进程申请成功的用户态总内存地址,包括DLL/EXE占用的地址和通过VirtualAlloc API Reserve的Memory Space数量,所以该计数器应该总大于Private Bytes。一般来说,Virtual Bytes跟Private Bytes的变化大致一致。由于内存分片的存在, Virtual Bytes跟Private Byes一般保持一个相对稳定的比例关系。当Virtual Bytes跟Private Bytes的比例关系大于2的时候,程序往往有比较严重的内存地址分片。
Processor object
Processor object记录系统中芯片的负载情况。由于普通程序并不刻意邦定到某个具体CPU上执行,所以在多CPU机器上观察Total Instance也就足够了
% Processor Time 该计数器跟Process下的% Processor Time的意义一样,不过这里记录的是所有进程带来的芯片,而不是针对具体某一个进程。通过把这个计数器跟Process下的同名计数器一起比较,就能看出系统的高CPU问题是否是由于单一的某个进程导致的
System
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 Switch雷同。
File Data Operations/sec
File Data Operations记录了当前系统中磁盘文件读写的频繁程度。通过观察该计数器跟其他性能指标的变化趋势,通常能够判断磁盘文件操作是否是性能瓶颈。类似的计数器还有Network Interface\Bytes total/sec
Memory
Memory object记录了当前系统中整体内存的统计信息。
Available Mbytes
Committed Bytes
Available Mbytes记录了当前剩余的物理内存数量。Committed Bytes记录了所有进程commit的内存数量。结合两个计数器可以观察到:
1) 两者相加可以粗略估计系统总体可用内存多少,便于估计物理配置
2) 当Available Mbytes少于100MB的时候,说明系统总体内存吃紧,会影响到整个系统所有进程的性能。应该考虑增加物理内存或者监察内存泄露
3) 通过比较Process\Private Bytes跟Virtual Bytes,便于进一步确认是否有内存泄露,判断内存泄露是否是某一单个进程导致
Free System Page Table Entries,Pool Paged Bytes和Pool Paged Bytes
这三个计数器可以衡量核心态空闲内存的数量。特别是当使用/3GB开关后,核心态内存地址被压缩,容易导致核心态内存不足,继而引发一些非常妖怪的问题。可以参考前面提到的文章:
How to use the /userva switch with the /3GB switch to tune the User-mode space to a value between 2 GB and 3 GB
http://support.microsoft.com/kb/316739/en-us
.NET CLR Memory
.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) 内存泄露,内存分片导致内存压力
如果目标程序是ASP.NET,在ASP.NET开头的object中,下面这些计数器对于测量ASP.NET的性能非常有用。由于不少计数器存在于多个object类别中,下面只列出具体的计数器名字,而不去对应到具体的object:
Application Restarts
Application Restarts记录了ASP.NET Application Domain重启的次数。导致ASP.NET appDomain重启的原因往往是虚拟目录中被修改。比如修改了web.config文件,或者防毒程序对虚拟目录进行扫描。通过该计数器可以观察是否有异常的重启现象
Request Execution time
Request Execution time记录了请求的执行时间,是衡量ASP.NET性能的最直接参数。通过该计数器的平均值来衡量性能是否合乎预期值。需要注意的地方是由于Windows并非实时系统,所以不能用峰值来衡量整体性能。比如当GC发生的时候,请求执行时间肯定都要超过GC的时间。所以平均值才是有效的标准
Request Current
Request Current记录了当前正在处理的和等待处理的请求。最理想的情况是Request Current等于CPU的数量,这说明请求跟硬件资源能并发处理的能力恰好吻合,硬件投资正运行在最优状态。但是一般说来,当负荷比较大的时候,Request Current也随着增高。如果Request Current在一段时间内有超过10的情况,说明性能有问题。注意观察这个时候对应的CPU情况和其他的资源。如果CPU不高,很可能是程序中有blocking发生,比如等待数据库请求,导致请求无法及时完成。
Request/second
Request/second计数器记录了每秒钟到达ASP.NET的请求数。这是衡量ASP.NET负载的直接参数。注意观察Request/second是否超过程序的预期吞吐量。如果Request/Second有突发的波动,注意看是否有拒绝服务攻击。通过把Request/second,Request Current, Request Execution time和系统资源一起比较,往往能够看出来ASP.NET整体性能的变化和各个因素之间的影响
Request in Application Queue
当ASP.NET没有空余的工作线程来处理新进入的请求的时候,新的请求会被放到Application Queue中。当Application Queue堆积的请求也超过设定数值的时候,ASP.NET直接返回503 Server too busy错误,同时丢弃该请求。所以正常情况下,Request in Application Queue应该总为0,否则说明已经有请求堆积,性能问题严重
相关文章推荐
- 一些重要的性能计数器
- 一些重要的计数器
- 一些重要的计数器
- 一些非常重要的iOS苹果官方文档地址列表
- 关于链表的一些重要操作(Important operations on a Linked List)
- 一些比较重要的算法
- 计算机编程中一些重要的算法
- spark安装过程中一些重要的问题
- 一些最重要的查询和过滤(most important queries and filters)
- 一些比较重要的经验
- Linux学习之CentOS(十七)--与Linux文件和目录管理相关的一些重要命令①
- IP 地址的一些重要特点
- Document对象中的一些重要的属性和方法(笔记)
- AOP的一些重要概念
- 一些重要的算法
- Struts2中一些重要概念的理解
- java语言中解决一些安全问题的技巧(安全编程非常重要标签)
- SQL Server 一些重要视图3
- 一些比较重要的算法(转)
- 计算机编程中一些重要的算法