一些重要的性能计数器(转载)

Process object下的所有计数器。51Testing软件测试网)b$BH0q hDZ

Processor object下的所有计数器

Z Ccl2AI;Y+e{K[378079

System object下的所有计数器

Qq/P\$Z%wj378079

Memory object下的所有计数器51Testing软件测试网s$z"y8b:Ne E

 

i}4|"gb!nmc378079

如果客户的程序是.NET程序，还会添加.NET开头的object下的所有技术其51Testing软件测试网#K!|GXFX&A+S o'Z2Owo

如果客户使用ASP.NET，还会添加ASP.NET开头的object下的所有技术其

(^^T{!^(u378079

 

LB-hu*{G378079

分析性能日志的时候，我会重点观察下面这些计数器

(^.@ t&c `/w$f378079

 51Testing软件测试网}5E Y`d*| m G

Process object51Testing软件测试网s u6O.] f"kMl

Process object中的计数器可以针对目标进程分析内存，CPU,线程数目和handle数目。首先要确定目标进程，然后分析目标进程的下面一些计数器：

D3@#LjL(\FuC/j378079

 51Testing软件测试网/AL \4G d){~

% Processor Time51Testing软件测试网 e\9`;E:t

该计数器是该进程占用CPU资源的指标。当进程繁忙的时候，CPU平均占用率应该在80%以内。如果超过该数值，程序可以认为发生了high CPU的问题。另外一种问题是CPU波动幅度大。虽然平均占用率不高，但是上下跳动频繁。在某一个短时间段里面，会有连续高CPU的情况出现。51Testing软件测试网/q*V7JG `

 51Testing软件测试网 trVG2]P

Handle Count

?i.DSyn'rZ
U-ue4|&[378079

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

pz({.H;x
l6h LJ!~378079

 51Testing软件测试网3h$\8rw }w}

ID Process51Testing软件测试网O,R'~9?*Zxh5K

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

2g$L7\Q)A:GQ"` U378079

 51Testing软件测试网3LeA|[U.T#@8W

Private Bytes

&qty)Mu378079

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

;\P!F,|4P R#sA378079

 51Testing软件测试网1v$w9_'i8ST)E

Virtual Bytes51Testing软件测试网 yce@rP+D

该计数器记录了当前进程申请成功的用户态总内存地址，包括DLL/EXE占用的地址和通过VirtualAlloc API Reserve的Memory Space数量，所以该计数器应该总大于Private Bytes。一般来说，Virtual Bytes跟Private Bytes的变化大致一致。由于内存分片的存在，Virtual Bytes跟Private Byes一般保持一个相对稳定的比例关系。当Virtual Bytes跟Private Bytes的比例关系大于2的时候，程序往往有比较严重的内存地址分片。51Testing软件测试网l2w({N6l~D
u
K e

Processor object51Testing软件测试网0H9t_6Dl)?6P

Processor object记录系统中芯片的负载情况。由于普通程序并不刻意邦定到某个具体CPU上执行，所以在多CPU机器上观察Total Instance也就足够了51Testing软件测试网i(F+Y;m0Q"jd

 51Testing软件测试网+E;O w)V0D7h3^

% Processor Time该计数器跟Process下的% Processor Time的意义一样，不过这里记录的是所有进程带来的芯片，而不是针对具体某一个进程。通过把这个计数器跟Process下的同名计数器一起比较，就能看出系统的高CPU问题是否是由于单一的某个进程导致的51Testing软件测试网*dfLTg
J/qy o n!P9wp

 51Testing软件测试网n7_'{H?;Dbfi@

System51Testing软件测试网d,QY$n/aM

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

^&E0ZZ)f+i1L@378079

 

x*dJ
cB#~)s%Y s6y
I378079

Context Switch/sec

/Qt*k"|l| r%M378079

Context Switch标示了系统中整体线程的调度，切换频率。线程切换是开销比较大的操作。频繁的线程切换导大量CPU周期被浪费。所以看到高CPU的时候，一定要跟Context Switch一起比较。如果两者有相同的变化趋势，高CPU往往是由于contention导致的，而不是死循环。51Testing软件测试网 e0a7{S*U#o })z?.v

 51Testing软件测试网:c9w;ngQ yeV?H

Exception Dispatches/sec51Testing软件测试网"rJZ(q @ C5cF

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

&z&t'|8xXu9P378079

 51Testing软件测试网0\LhPU7i _^?

File Data Operations/sec

Nr|@k-w*D378079

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

:c9A`a%uS9@0h378079

 51Testing软件测试网7F5\,L^+u
j k$`Ot^

Memory

D/W C*Q/L9v378079

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

W$Bjm/P9BjEt378079

 

&ySKoh_378079

Available Mbytes

u
q3G7X-A4C0@&Z378079

Committed Bytes51Testing软件测试网
h|M;e'H#t;F^ ul~*{ e

Available Mbytes记录了当前剩余的物理内存数量。Committed Bytes记录了所有进程commit的内存数量。结合两个计数器可以观察到：51Testing软件测试网cf%Mix4M M]

 

Q;{Ok:f5[*t378079

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

`-[|*y#rn?Z\378079

2)当Available Mbytes少于100MB的时候，说明系统总体内存吃紧，会影响到整个系统所有进程的性能。应该考虑增加物理内存或者监察内存泄露

` y Iq.b+A5z378079

3)通过比较Process\Private Bytes跟Virtual Bytes，便于进一步确认是否有内存泄露，判断内存泄露是否是某一单个进程导致51Testing软件测试网I Q/xvZ6H

 51Testing软件测试网XT2K~!z`9Ar

Free System Page Table Entries，Pool Paged Bytes和Pool Paged Bytes51Testing软件测试网T/A}E)h[Y

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

vFT[)X
M378079

 

8CI4W7M#}378079

How to use the /userva switch with the /3GB switch to tune the User-mode space to a value between 2 GB and 3 GB51Testing软件测试网AN {3MVh0hs

http://support.microsoft.com/kb/316739/en-us

 

'ZRM)L|O,J378079

.NET CLR Memory

SuZ_;|(~&_0qLG378079

.NET CLR Memory object记录了CLR进程中跟CLR相关的内存信息。该类别下的所有计数器都很有意思，而且意思也非常直接。建议用一个例子程序进行测试和研究。下面是两个最常用的计数器51Testing软件测试网 A`8r6qq|

 51Testing软件测试网v'c'v)RF;m;k+v|

Bytes in all heaps

9]$I8d.Y{z,^%M1F378079

Bytes in all heaps记录了上次GC发生时候所统计到的，进程中不能被回收的所有CLR object占用的内存空间。该计数器不是实时的，每次GC发生的时候该计数器才更新。跟同一进程的Process\Private bytes比较，可以区分出managed heap和native memory的变化情况。对于memory leak，便于区分是managed heap的leak还是native memory的leak51Testing软件测试网r(C!`Ex$B

 

#RZ1k)ysTR%eU)Qz378079

%Time in GC

%gx@ TrL378079

%Time in GC记录了GC发生的频繁程度。一般来说15%以内算比较正常。当超过20%说明GC发生过于频繁。由于GC不仅仅带来很高的CPU开销，还需要挂起目标进程的CLR线程，所以高频率GC是非常危险的。通过跟CPU利用率和其他性能指标比较，往往能够看出GC对性能的影响。高频率的GC往往因为51Testing软件测试网-U(BU9K0{}

1)负载过高51Testing软件测试网:Hk].^Zo

2)不合理的架构，对内存使用效率不高51Testing软件测试网5o}!n q0A d T$W#lo

3)内存泄露，内存分片导致内存压力

/_G:j%f^&X378079

 51Testing软件测试网"id s%T{ B6BAX

如果目标程序是ASP.NET，在ASP.NET开头的object中，下面这些计数器对于测量ASP.NET的性能非常有用。由于不少计数器存在于多个object类别中，下面只列出具体的计数器名字，而不去对应到具体的object:

q0e3Y1qc.{5U378079

 

IX-|5g,Q(Q
a?i378079

Application Restarts

X2C%~n,PW Bg378079

Application Restarts记录了ASP.NET Application Domain重启的次数。导致ASP.NET appDomain重启的原因往往是虚拟目录中被修改。比如修改了web.config文件，或者防毒程序对虚拟目录进行扫描。通过该计数器可以观察是否有异常的重启现象51Testing软件测试网)c,n*e?
Cn"p9j

 

)X8y3[E.a@#TW0]378079

Request Execution time51Testing软件测试网 y&Y$` R3hw~/n6c

Request Execution time记录了请求的执行时间，是衡量ASP.NET性能的最直接参数。通过该计数器的平均值来衡量性能是否合乎预期值。需要注意的地方是由于Windows并非实时系统，所以不能用峰值来衡量整体性能。比如当GC发生的时候，请求执行时间肯定都要超过GC的时间。所以平均值才是有效的标准

c"GG3x8W{&G378079

 51Testing软件测试网 {1[/B'_/f [ E

Request Current51Testing软件测试网-{"T8bbX3TM;l#M_B[

Request Current记录了当前正在处理的和等待处理的请求。最理想的情况是Request Current等于CPU的数量，这说明请求跟硬件资源能并发处理的能力恰好吻合，硬件投资正运行在最优状态。但是一般说来，当负荷比较大的时候，Request Current也随着增高。如果Request Current在一段时间内有超过10的情况，说明性能有问题。注意观察这个时候对应的CPU情况和其他的资源。如果CPU不高，很可能是程序中有blocking发生，比如等待数据库请求，导致请求无法及时完成。

BZr P!h8n378079

 51Testing软件测试网$`~.s)E'T3TF

Request/second

?#GL$K
b$d/ET _378079

Request/second计数器记录了每秒钟到达ASP.NET的请求数。这是衡量ASP.NET负载的直接参数。注意观察Request/second是否超过程序的预期吞吐量。如果Request/Second有突发的波动，注意看是否有拒绝服务攻击。通过把Request/second,Request Current, Request Execution time和系统资源一起比较，往往能够看出来ASP.NET整体性能的变化和各个因素之间的影响51Testing软件测试网z Av R%r
Rg

 

P z}Kn#]N378079

Request in Application Queue

4xOl)X f*C(_378079

当ASP.NET没有空余的工作线程来处理新进入的请求的时候，新的请求会被放到Application Queue中。当Application Queue堆积的请求也超过设定数值的时候，ASP.NET直接返回503 Server too busy错误，同时丢弃该请求。所以正常情况下，Request in Application Queue应该总为0，否则说明已经有请求堆积，性能问题严重51Testing软件测试网1x R$Y4b9A-o8`*s/tW

 

O0S2\M.^378079

文章作者：lixiong录入时间：2006-11-6来源：http://lixiong.cnblogs.com/