Windows 性能监视器的基本指标（CPU,内存,硬盘参数） - 休眠火山0112

时间：2024-02-16 09:47:49

Windows 性能监视器的基本指标（CPU,内存,硬盘参数）

转载：http://kms.lenovots.com/kb/article.php?id=7045

Windows 性能监视器的基本指标（CPU,内存,硬盘参数）

 

        作为一个系统工程师来说，要看懂监控的数据至关重要，关系着优化和分析出现的问题，因此，今天给出Windows 性能监视器的一些基本指标（CPU,内存,硬盘参数），希望对大家将来优化和分析问题提供帮忙。

Windows -Processor


指标名称
指标描述
指标范围
指标单位

CPU利用率
（% Processor Time）
% Processor Time指处理器执行非闲置线程时间的百分比。这个计数器设计成用来作为处理器活动的主要指示器。它通过在每个时间间隔中衡量处理器用于执行闲置处理线程的时间，并且用100%减去该值得出。可将其视为范例间隔用于做有用工作的百分比。
根据应用系统情况，在80%±5%范围内波动为宜。过低，则服务器CPU利用率不高；过高，则CPU可能成为系统的处理瓶颈。
%

中断率
（Interrupts/sec.）
每秒钟设备中断处理器的次数。在完成一个任务或需要注意时，装置会发出中断讯号给处理器。可以产生中断的装置包括系统定时器、鼠标、数据通讯联机、网络卡以及其它的外部装置。在中断过程中，一般的执行绪执行将被暂停，而且一个中断可以使处理器切换到另一个具有较高优先等级的执行绪。频率中断是频繁和周期性的，并且中断动作在背景执行。
取决于处理器，越低越好；不宜超过1,000；
如果该值显著增加而系统活动没有相应的增加，则表明存在硬件问题，需要检查引起中断的网络适配器、磁盘或其他硬件。
次/sec

系统调用率
System Call/sec.
指运行在计算机上的所有处理器调用操作系统服务例行程序的综合速率。这些例行程序执行所有在计算机上的如安排和同步活动等基本的程序，并提供对非图形设备、内存管理和名称空间管理的访问。
如果Interrupts/sec大于System Calls/sec.,则系统中某一硬件设备产生过多的中断。
次/sec

Processor Queue Length
处理器队列的线程数量。此计数器只显示就绪线程，而不是正在运行的线程。
如果处理器队列中总是有两个以上的线程通常表示处理器堵塞。		  

进程切换率
Context Switches/sec
指计算机上的所有处理器全都从一个线程转换到另一个线程的综合速率。当正在运行的线程自动放弃处理器时出现上下文转换，由一个有更高优先就绪的线程占先或在用户模式和特权 (内核) 模式之间转换以使用执行或分系统服务
如果此计数器的数值较大，则表明锁定竞争很激烈，或者线程在用户和内核模式之间频繁切换。		  

Windows -Memory 

指标名称
指标描述
指标范围
指标单位

Pages/sec
Pages Input/sec
Pages Output/sec
Page Fault/sec
Page Faults/sec 是处理器每秒钟处理的错误页（包括软错误和硬错误）。Pages Input/sec 是为了解决硬错误页，从硬盘上读取的页数， 而Page Reads/sec是为了解决硬错误，从硬盘读取的次数。Pages/sec是Pages Input/sec 和Pages Output/sec 的总和。
该系列指标是可以显示导致系统范围延缓类型错误的主要指示器。
当处理器向内存指定的位置请求一页（可能是数据或代码）出现错误时，这就构成一个Page Fault。如果该页在内存的其他位置，该错误被称为软错误（ 用Transition Fault/sec衡量）； 如果该页必须从硬盘上重新读取时， 被称为硬错误。许多处理器可以在有大软错误的情况下继续操作。但是， 硬错误可以导致明显的拖延。
如果Page Reads/Sec持续保持为5，表示可能内存不足。Page/sec推荐0-20。如果服务器没有足够的内存处理其工作负荷，此数值将一直很高。如果大于80，表示有问题(太多的读写数据操作要访问磁盘，可考虑增加内存或优化读写数据的算法)。
该系列计数器的值比较低， 说明响应请求比较快， 否则可能是服务器系统内存短缺引起（也可能是缓存太大， 导致系统内存太少）。
次/sec

Available Bytes
显示出当前空闲的物理内存总量，它等于分配给待机(缓存的)、空闲和零分页列表内存的总和。
空闲内存可以马上使用; 清零内存是由零值填满的内存页，用来防止后续进程获得旧进程使用的数据; 待机内存是从进程工作集(其物理内存)中删除然后进入磁盘的内存，但是该内存仍然可以收回。该指标仅显示最后一次观察到的值，不是平均值。
当这个数值变小时，Windows开始频繁地调用磁盘页面文件。如果这个数值很小，例如小于5 MB，系统会将大部分时间消耗在操作页面文件上。
一般要保留10%的可用内存。最低不能<4M，此值过小可能是内存不足或内存泄漏。		  

Committed Bytes
是指以字节表示的确认虚拟内存，是磁盘页面文件上保留空间的物理内存。
不超过物理内存的 75%		  
       

Windows – Disk 

指标名称
指标描述
指标范围
指标单位

% Disk Time
指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。
正常值<10，此值过大表示耗费太多时间来访问磁盘，可考虑增加内存、更换更快的硬盘、优化读写数据的算法。若数值持续超过80 (此时处理器及网络连接并没有饱和)，则可能是内存泄漏。		  

Current Disk Queue Length
是在收集性能数据时磁盘上当前的请求数量。它还包括在收集时处于服务的请求。这是瞬间的快照，不是时间间隔的平均值。多轴磁盘设备能有一次处于运行状态的多重请求，但是其他同期请求正在等待服务。此计数器会反映暂时的高或低的队列长度，但是如果磁盘驱动器*持续运行，它有可能一直处于高的状态。
请求的延迟与此队列的长度减去磁盘的轴数成正比。为了提高性能，此差应该平均小于二。		  

Avg.Disk Queue Length
Avg. Disk Read Queue Length
Avg. Disk Write Queue Length
指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。
Avg.Disk Queue Length正常值<0.5，此值过大表示磁盘IO太慢，要更换更快的硬盘。		  
       

 

性能监视器- Performance Monitor

性能监视器是Windows自带的系统资源和性能监视工具. 性能监视器能够量化地提供CPU使用率, 内存分配状况, 异常派发情况, 线程调度频率等信息. ASP.NET能够提供每秒钟的请求数目, 请求响应时间等等. 性能监视器能够监视一段时间内上述资源的利用情况, 提供平均值和峰值.

 

性能监视器有助于获取关于性能的具体指标, 监视问题出现时系统资源的变化情况. 通过检查性能监视器中一些重要计数器的变化情况, 往往能够找到一些比较有用的线索. 比如比较ASP.NET每秒请求数目, 请求响应时间和CPU利用率是否有相同的变化曲线就能看出性能是否跟负载相关.

 

解决性能问题的时候, 往往会让客户添加下面一些计数器进行性能收集.

  • 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%以内. 如果超过该数值, 可以认为程序发生了高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了的内存地址数量, 所以该计数器应该总大于Private Bytes. 一般说来, Virtual Bytes与Private Bytes的变化大致一致. 由于内存分片的存在, Virtual Bytes与Private Bytes一般保持一个相对稳定的比例关系. 当Virtual Bytes与Private Bytes的比例大于2的时候, 程序往往有比较严重的内存地址分片.

 

Processor object

==============

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

 

%Processor Time

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

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

 

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

 

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开关后, 核心态内存地址被压缩, 容易导致核心态内存不足, 继而引发一些非常奇怪的问题.

 

.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. 内存泄露, 内存碎片导致内存压力.

ASP.NET的性能监视

============

如果目标程序时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 Application Queue应该总为0, 否则说明已经有请求堆积, 性能问题严重.

 

摘自<Windows用户态程序高效排错>

 

相关文章