一些重要的性能计数器
2010-07-15 20:25
232 查看
解决性能问题的时候,我往往会让客户添加下面一些计数器进行性能收集。
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,否则说明已经有请求堆积,性能问题严重
相关文章推荐
- 【转】一些重要的计数器
- 一些重要的计数器
- 一些重要的计数器
- 一些性能计数器的说明
- 整理一些PHP函数,这些函数用的不是非常多,但是又非常重要,如果适当的用起来,有可以提升性能
- 整理提高PHP性能的一些技巧
- Android开发网上的一些重要知识点【1】
- ORACLE 查看CPU使用率最高的语句及一些性能查询语句
- check_mk自定义监控插件监控IIS站点的性能计数器
- IT人的学习方法论-4 一些重要的能力
- Windows性能计数器分析
- 服务器性能监控之性能计数器
- RelativeLayout用到的一些重要的属性(转)
- Windows性能计数器--磁盘性能分析Disk
- 3星|《IBM商业价值报告:区块链》:一些重要行业对区块链的态度和已经发生的区块链的应用
- 十大监视SQL Server性能的计数器
- SQL Server 2008 安装过程中遇到“性能计数器注册表配置单元一致性”检查失败 问题的解决方法【已验证
- Windows 性能计数器
- Java编程性能优化一些事儿
- 快速掌握SQL Server中一些常见的性能问题 1/3