Object |
Counters |
Descrīption |
Reference value |
Memory |
Available Mbytes |
可用物理内存数.如果Available Mbytes的值很小（4 MB或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。 |
4 MB或更小，至少要有10%的物理内存值 |
Page/sec (Input/Out) |
为了解析硬页错误，从磁盘取出或写入的页数。 一般如果Page/sec持续高于几百，那么您应该进一步研究页交换活动。有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。Pages/sec的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。 |
推荐00-20 如果服务器没有足够的内存处理其工作负荷，此数值将一直很高。如果大于80，表示有问题(太多的读写数据操作要访问磁盘，可考虑增加内存或优化读写数据的算法)。 该系列计数器的值比较低说明响应请求比较快， 否则可能是服务器系统内存短缺引起（也可能是缓存太大， 导致系统内存太少）。 >5越低越好 |
|
Page Fault |
处理器每秒处理的错误页（包括软/硬错误）。 当处理器向内存指定的位置请求一页（可能是数据或代码）出现错误时，这就构成一个Page Fault。如果该页在内存的其他位置，该错误被称为软错误（用Transition Fault/sec记数器衡量）；如果该页必须从硬盘上重新读取时，被称为硬错误。许多处理器可以在有大量软错误的情况下继续操作。但是，硬错误可以导致明显的拖延。 |
||
Page Input/sec |
为了解决硬错误页，从磁盘上读取的页数。 |
||
Page Output/sec |
|
||
Page reads/sec |
为了解决硬错误页，从磁盘上读取的次数。解析对内存的引用，必须读取页文件的次数。 阈值为>5.越低越好。大数值表示磁盘读而不是缓存读。 |
||
Cache Bytes |
文件系统缓存，默认情况下为50%的可用物理内存。如IIS5.0运行内存不够时，它会自动整理缓存。需要关注该计数器的趋势变化 |
|
|
内存泄露 |
如果您怀疑有内存泄露，请监视Memory\\ Available Bytes和Memory\\ Committed Bytes，以观察内存行为，并监视您认为可能在泄露内存的进程的Process\\Private Bytes、Process\\Working Set和Process\\Handle Count。如果您怀疑是内核模式进程导致了泄露，则还应该监视Memory\\Pool Nonpaged Bytes、Memory\\ Pool Nonpaged Allocs和Process(process_name)\\ Pool Nonpaged Bytes。 |
如果发生了内存泄漏,进程的两个计数器process\private bytes计数器和process\workingset 计数器的值往往会升高,同时内存计数器avaiable bytes的值会降低 |
|
Process |
Page Faults/sec |
将进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。 |
|
Private Bytes |
此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。 |
|
|
Work set |
处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。 |
|
|
Processor |
% Processor Time |
被消耗的处理器时间数量.如果服务器专用于sql server可接受的最大上限是80% -85%.也就是常见的CPU使用率. |
|
ProcessorQueue Length |
判断CPU瓶颈,如果processor queue length显示的队列长度保持不变(>=2)并且处理器的利用率%Processor time超过90%,那么很可能存在处理器瓶颈.如果发现processor queue length显示的队列长度超过2,而处理器的利用率却一直很低,或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈. |
|
|
Physical Disk |
%DiskTime |
指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。 正常值<10，此值过大表示耗费太多时间来访问磁盘，可考虑增加内存、更换更快的硬盘、优化读写数据的算法。若数值持续超过80 (此时处理器及网络连接并没有饱和)，则可能是内存泄漏。 |
|
CurrentDiskQueueLength |
读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。(磁盘数1.5-2倍) |
|
|
Avg.Disk Queue Length Avg.Disk Read QueueLength Avg.Disk Write QueueLength Disk Read/sec Disk Write/sec |
读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。 磁盘瓶颈判断公式： 每磁盘的I/O数=（读次数+（4*写次数））/磁盘个数。 如果计算出来的每磁盘的I/O数大于磁盘的处理能力，那么磁盘存在瓶颈。 |
Avg.DiskQueue Length正常值<0.5，此值过大表示磁盘IO太慢，要更换更快的硬盘。 |
| 监控类型 |
|
|
|
|
Loadrunner自带 |
% Processor Time |
CPU使用率，如果大于80%表示服务器繁忙。 |
Available Mbytes |
可用物理内存，如果内存持续消耗，而没有回收，表示可能存在问题。 |
||
% Disk Time |
磁盘使用率，如果大于80%表示磁盘繁忙。 |
||
Threads |
服务器使用线程数，如果持续增长，且无回收，表示可能存在问题。 |
||
SQLServer数据库 |
Loadrunner自带 |
Full Scans/sec |
全表扫描，如果该值持续较大或偶尔较大，表示可能存在堆表扫描。 |
Number of Deadlocks/sec |
死锁的数量，应该始终保持为0。 |
||
Average Wait Time (ms) |
锁等待解除时间，平均>25ms，可能需要优化SQL |
||
硬盘资源 |
Loadrunner自带 |
Avg Disk Queue Length |
平均磁盘队列长度，正常情况下的队列长度应该在1-2之间，过长的对列长度说明系统存在着磁盘IO瓶颈。 |
Avg Disk Read Queue Length |
平均磁盘读队列长度，正常情况下的队列长度应该在1-2之间，过长的对列长度说明系统存在着磁盘IO瓶颈。 |
||
Avg Disk Write Queue Length |
|
===============================================
内存： page fault/sec: (pages/sec 硬+transition/sec 软)
page reads/sec 页面的读取率 （硬）
吞吐量比较低，cpu利用率高，上下文切换在15000以上
性能调优原则，尽量减少磁盘IO
磁盘使用率 disk time；磁盘读和写的比特数（达到几十到上百M就要注意） 磁盘剩余空间10%以上
网络： pakets/sec（包，不具体到字节，不够直观） Bytes total/sec(具体到字节，所以关注这个，该值×8然后再与带宽的一半比较，小于则没有瓶颈，一般7位以下的都没问题）
linux可以设置最大堆内存为2G左右，windows 32位为1G左右，再高也不起什么作用
==================================================================================================
一、内存重要指标 Memroy
1、对于Windows系统而言，可用物理内存不要少于1%。
比如：2G内存，如果可用物理内存20M或者更少，则要引起注意，怀疑内存处理能力不足。
2、观察可用物理内存曲线时，在测试过程中提交的物理内存会在测试结束后慢慢释放回来，则这种系统为正常的内存表现。
3、系统的内存存在大量软错误（在内存的其它位置找到该资源）的情况下能正常工作，但是如果硬错误（必须重新回磁盘找数据）较多，则会对系统的性能带来影响。
4、Page Reads/sec (页面读取率)：如果该值持续大于内存的1%（如果2G内存，该值持续大于20M），则怀疑内存不足。
说明：在Windows资源监控中，Memory部分：Page Faults/sec和Pages/sec也要监控。
二、磁盘的重要指标 Physical Disk
1、Disk Reads(Writes)/sec 磁盘读或写的阈值：
一般不超过几十M
如果发现磁盘的读或写超过过了几十M或者上百M，会严重影响系统性能。怀疑是磁盘的瓶颈。
2、性能调优的一个重要原则就是：尽量减少磁盘IO
说明：Disk I/O 就是磁盘的in或out 读/写
3、磁盘的I/O绝对不可避免（磁盘和内存的交互必不可少），但是可以尽量减少。
举例：
Java如何提高系统性能（软件本身）：
1）使用缓存Cache: 以空间换时间
更多的内存空间 -- 更快读写时间
提前将磁盘中的数据，读入内存，供程序使用
2）使用单例
保证一个类在系统中最多只创建一个实例(对象)
三、网络重要指标：
Bytes Total/sec (重要) 和 Packets/sec
1、Bytes Total/sec: 将该值乘以8，与网络带宽的一半进行比较，如果小于带宽的一般，则一般没有问题。
2、1Byte=8bits
说明：网络商带宽单位一般都用bit，显得数值大。比如100Mbps
四、性能分析--监控服务器资源
（客户端在测试时，不需要监控，因为主要对AUT监控，主要是其服务器）
1、为何只监控服务器：测试AUT的性能，只需关注AUT的服务器即可，客户端只需偶尔观察：使用安装LR的测试机（模拟客户端）测试时，偶尔打开本机的任务管理器，点击“性能窗口”，查看，保证正常使用即可。
2、如何监控服务器的内存泄露？
--首先正常测试（监控正常指标），当发现被测系统的内存曲线不正常时，再去测试三项指标。
1）正常的情况：物理内存在测试过程中不断被吃进，在测试结束后释放回来。
2）三项指标：（两升一降）
process\private bytes 和 process\working set 计数器 升高
available bytes 的值降低
3、如何判断应用程序的问题：CPU平均值高，吞吐率整体水平不高甚至有所下降，但是上下文切换很高（正常系统中偶尔的、适当的上下文切换是有必要的，若频繁，则有问题），说明系统应用程序存在设计或代码方面的问题。
六、CPU各项重要资源：
1、%Processor time: CPU忙的时间的百分比，当该值的平均值超过80%或者85%时（(yu)阈值），一般怀疑CPU有瓶颈。
---如果CPU的确有瓶颈（处理能力不足），可以添加CPU或者置换性能较高的CPU.
（硬件问题较易解决，软件问题较难解决）
2、Processor Queue Length
1）阈值：单CPU不应大于2；如果是n块CPU，则该值不应大于n+1;
2）双核，则n=2 （虽然双核性能不及2块CPU，但也当做2块CPU处理）
3、注意：在服务器资源中，如果没有特殊说明，则都是值 平均值。（最大值和最小值只作为一般参考）
六、CPU各项重要资源：
1、%Processor time: CPU忙的时间的百分比，当该值的平均值超过80%或者85%时（(yu)阈值），一般怀疑CPU有瓶颈。
---如果CPU的确有瓶颈（处理能力不足），可以添加CPU或者置换性能较高的CPU.
（硬件问题较易解决，软件问题较难解决）
2、Processor Queue Length
1）阈值：单CPU不应大于2；如果是n块CPU，则该值不应大于n+1;
2）双核，则n=2 （虽然双核性能不及2块CPU，但也当做2块CPU处理）
3、注意：在服务器资源中，如果没有特殊说明，则都是值 平均值。（最大值和最小值只作为一般参考）
1)判断CPU瓶颈
1， %processor time 平均值大于95
2， processor queue length大于2(大于处理器个数+1).
3， CPU空闲时间为零(zero percent idle CPU)
4， 过高的用户占用CPU时间(%User Time)
5, 过高的系统占用CPU时间(%Priviliaged Time：长期大于90%或者95%)
备注：
%User time(processor_total)表示耗费CPU的数据库操作，如排序，执行aggregatefunctions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值
（1）判断CPU瓶颈,如果processor queue length显示的队列长度保持不变(>=2)并且处理器的利用率%Processor time超过90%,那么很可能存在处理器瓶颈.
（2）判断CPU瓶颈阻塞，如果发现processor queue length显示的队列长度超过2,而处理器的利用率却一直很低,则存在处理器阻塞问题,这里处理器一般不是瓶颈.
2)判断内存瓶颈与内存泄漏
1，如果发生了内存泄漏,进程的两个计数器process\private bytes计数器和process\workingset 计数器的值往往会升高,同时avaiable bytes的值会降低。
2，如果Available Mbytes（剩余物理内存数）的值很小(4 MB 或更小)，则说明计算机上总的内存可能不足，或某程序没有释放内存。
3)定位磁盘瓶颈
1， % Disk Time 和Avg.DiskQueue Length 的值 (应不大于组成物理磁盘的主轴数的1.5 到2倍) 很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。
2，Physical Disk\ Disk Reads/sec and Disk Writes/sec 大于20 ms,则有可能磁盘瓶颈
3，Avg.Disk sec/Transfer 盘中写入数据的平均时间，单位是秒，一般来说，定义该值小于15ms最为优异，介于15-30ms之间为良好，30-60ms之间为可以接受，超过60ms则需要考虑更换硬盘或硬盘的RAID方式了
4，Disk Transfers/sec 指在此盘上读取/写入操作速率。正常值<(Disk Bytes/sec)/3，此值过大表示系统要求的IO速度已接近硬盘的最大速度，要更换更快的硬盘。
备注：如果使用 RAID 设备，% Disk Time 计数器会指示大于 100% 的值。
Avg.DiskQueue Length正常值<0.5，此值过大表示磁盘IO太慢，要更换更快的硬盘。
4)定位网络瓶颈
Byte Total/sec 表示网络中接受和发送字节的速度，可以用该计数器来判断网络是否存在瓶颈（参考值：该计数器和网络带宽相除，<50%）
5)SQL Server 相关
1, SQLServer:CacheManage->Cache Hit Ratio 显示在高速缓存中找到数据的命中率。如果数值持续小于 85%， 则表示内存有问题。
2, SQLServer:Locks->LockWaits/sec 显示在当前进程完成之前强制其他进程等待的每秒锁定请求的数量。如果该值始终大于 0， 则表示事务有问题。
3, SQLServer:Databases->Transactions/sec 每秒为数据库启动的事务数
Full Scans/sec |
全表扫描，如果该值持续较大或偶尔较大，表示可能存在堆表扫描。 |
Number of Deadlocks/sec |
死锁的数量，应该始终保持为0。 |
Average Wait Time (ms) |
锁等待解除时间，平均>25ms，可能需要优化SQL |
===============================================================
1.处理器
合理 windows/linux cpu <80%
1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%
合理使用的范围在60%至70%。
2 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。
CPU资源成为系统性能的瓶颈的征兆:
很慢的响应时间(slow response time)
CPU空闲时间为零(zero percent idle CPU)
过高的用户占用CPU时间(high percent user CPU)
过高的系统占用CPU时间(high percent system CPU)
长时间的有很长的运行进程队列(large run queue size sustained over time)
2.
磁盘I/O：
1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。
2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。
I/O资源成为系统性能的瓶颈的征兆 :
过高的磁盘利用率(high disk utilization)
太长的磁盘等待队列(large disk queue length)
等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)
太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)
3.
数据库服务器：
SQL Server数据库：
1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。
2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。
3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。
4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。
Oracle数据库：
1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。
快存（共享SQL区）和数据字典快存的命中率：
select(sum(pins-reloads))/sum(pins) from v$librarycache;
select(sum(gets-getmisses))/sum(gets) from v$rowcache;
自由内存 select * from v$sgastat where name=’free memory’;
2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。
缓冲区高速缓存命中率：
select name,value from v$sysstat where name in (‘db block gets’,
‘consistent gets’,'physical reads’) ;
参考述语清单：
中文名称 |
英文名称 |
简写 |
具体含义 |
同一时间点并发 |
Same time points concurrent |
Points-Concurrent（POC.） |
指所有人在同一时间点只做某一个相同的业务，服务器的压力呈单一状态 |
同一时间段并发 |
The same time period concurrent |
Period-Concurrent (PEC.) |
指不同的人做不同的业务，服务器的压力呈混合、较真实状态 |
性能验收测试 |
Performance acceptance tests |
Acceptance-Tests |
验证测试结果是否能够达到《需求规格说明书》中的目标 |
性能压力测试 |
Performance stress tests |
Stress-Tests |
在满足《需求规格说明书》中的目标后，不断增加用户数，寻找系统的最佳并发数区间和最大并发数区间(最佳和最大并发数，以响应时间的最佳和最大为判断准则） |
性能稳定性测试 |
Performance sability tests |
Sability-Tests |
在最佳和最大并发数的状态上，测试长时间内系统的稳定性 |
性能崩溃测试 |
Performance crash test |
Crash-Test |
在最大并发数的基础上，不断增加并发数，获得系统失败率大于10%或者系统崩溃时的状态 |
单一业务 |
Single business |
Single-Business |
模拟的同一时间点并发某个业务 |
混合业务 |
Mixed business |
Mixed-Business |
模拟的同一时间段并发不同的业务 |
虚拟用户 |
Virtual users |
Vuser |
Loadrunner模拟的用户代称 |
集合点 |
Rendezvous |
Rendezvous |
Loadrunner中模拟所有用户在某一刻请求某一个事务 |
点击率 |
Hits/Sec |
Hits/Sec |
每秒钟Vuser向服务器请求的请求数量 |
服务器网络流量 |
Server network traffic |
Throughput |
应用服务器向客户端发送的下行宽带流量 |
事务 |
Transactions |
Transactions |
Loadrunner中定义的某笔业务名称 |
每秒事务数 |
Transactions per second |
TPS |
系统每秒钟一共处理了多少笔业务 |
每分钟事务数 |
Transactions per Minute |
TPM |
系统每分钟一共处理了多少笔业务 |
24小时事务数 |
Transactions per 24hours |
TP24H |
系统24小时共处理了多少笔业务 |
总事务数 |
Total transactions |
TTpass |
在测试期间，系统一共处理了多少笔业务 |
事务通过率 |
Transaction through rate |
Tpass% |
在测试期间，系统一共正确处理了多少笔业务 |
平均响应时间 |
The average response time |
ART |
某笔业务处理完毕所需要的时间 |
90%响应时间 |
The Transaction :90% of the peak response time |
90%RT |
所有业务所需要的时间90%的比例都比此值小的时间，也就是90%的数据中所拥有的峰值。90%响应时间，可能表述为75%、80%等 |
最大响应时间 |
The Transaction :Max. Response time |
Max RT |
最大响应时间，即所采集数据中的最大值 |
标准差 |
Standard deviation |
Std. |
标准差，标准差越大，说明该笔业务的响应时间越不稳定，越小越稳定，但如果为0表示系统或脚本存在问题 |
CPU使用率 |
CPU usage |
CPU% |
CPU的使用率，大于80%表示繁忙 |
可用物理内存 |
Available physical memory |
AMB% |
可用物理内存剩余量，应占所有的20% |
磁盘使用率 |
Disk Usage |
Disk% |
磁盘使用率，大于80%表示繁忙 |
服务器线程数 |
The number of server threads |
Threads |
系统所使用的线程数 |
=================================
Memory:
·Available Mbytes
简述：可用物理内存数.如果Available Mbytes的值很小（4 MB或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。
参考值：4 MB或更小，至少要有10%的物理内存值
·Page/sec (Input/Out)
简述：为了解析硬页错误，从磁盘取出或写入的页数。
一般如果Page/sec持续高于几百，那么您应该进一步研究页交换活动。有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。Pages/sec的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。
参考值：
·Page Fault
简述：处理器每秒处理的错误页（包括软/硬错误）。当处理器向内存指定的位置请求一页（可能是数据或代码）出现错误时，这就构成一个Page Fault。如果该页在内存的其他位置，该错误被称为软错误（用Transition Fault/sec记数器衡量）；如果该页必须从硬盘上重新读取时，被称为硬错误。许多处理器可以在有大量软错误的情况下继续操作。但是，硬错误可以导致明显的拖延。
参考值：
·Page Input/sec
简述：为了解决硬错误页，从磁盘上读取的页数。
参考值：
·Page reads/sec
简述：为了解决硬错误页，从磁盘上读取的次数。解析对内存的引用，必须读取页文件的次数。阈值为>5.越低越好。大数值表示磁盘读而不是缓存读。
参考值：
·Cache Bytes
简述：文件系统缓存，默认情况下为50%的可用物理内存。如IIS5.0运行内存不够时，它会自动整理缓存。需要关注该计数器的趋势变化。该指标只显示最后一次观察的值，它不是一个平均值。
参考值：
简述: 指在分页池中的字节 数，分页池是系统内存中可供对象使用的一个区域。
·pool nonpaged bytes
简述:指非分页池中的 字节数，非分页池中的字节数如果持续增加表示可能存在内存泄漏问题，需要进一步结合其他指标，来判断是否存在严重的内存泄漏还是其他原因引起的非分页池增加。
·内存泄露
简述：
如果您怀疑有内存泄露，请监视Memory\\ Available Bytes和Memory\\ Committed Bytes，以观察内存行为，并监视您认为可能在泄露内存的进程的Process\\Private Bytes、Process\\Working Set和Process\\Handle Count。如果您怀疑是内核模式进程导致了泄露，则还应该监视Memory\\Pool Nonpaged Bytes、Memory\\ Pool Nonpaged Allocs和Process(process_name)\\ Pool Nonpaged Bytes。
参考值：
Process
·Page Faults/sec
简述：将进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。指每秒钟出错页面的平均数量。
参考值：
·Private Bytes
简述：此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。
参考值：
·Work set
简述：处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。
参考值：
Processor
·% Processor Time
简述：CPU利用率，可以查看处理器是否处于饱和状态，此值的最佳范围为75%-95%，如果在性能监控过程中此值过低，表示CPU尚未充分利用，还 需要更大的负载压力，如果该值持续超过95%，就表示当前系统的瓶颈为CPU，此时可以考虑增加一个处理器或换一个性能更好的处理器。
参考值：
·ProcessorQueue Length
简述：判断CPU瓶颈,如果processor queue length显示的队列长度保持不变(>=2)并且处理器的利用率%Processor time超过90%,那么很可能存在处理器瓶颈.如果发现processor queue length显示的队列长度超过2,而处理器的利用率却一直很低,或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈.
参考值：
·interrupt/sec
简述：指处理器接收并维护硬件中断的平均值，单位是事件数/秒，这 个值说明了能够产生中断的设备（如系统时钟、鼠标、磁盘驱动器、网卡和其他外部设备）的活动情况，这些可以产生中断 的设备通常在完成了一项任务时中断处理器。
·%user time
简述：指处理器处于用户模式的时间百分比，也就是非内核操作用户进程所耗费的CPU时间。其值可以表示为CPU的数据库操作 （如查找、排序等活动）耗费的时间，如果该值很高，可以考虑增加索引、使用简单的表连接、水平分割大表格等方法来降低该值。
·%privileged Time
简述：指处理线程执行代码所花时间的百分比。如果该参数值和“physical disk”值一直很高，表明I/O有问题，可考虑采用更快的硬盘系统。
·%interrupte time
简述：处理器在实例间隔期间接受和服务硬件中断的时间。此 值间接表示了产生中断的设备的活动，如系统时钟、鼠标、磁盘驱动器、网卡和其他外部设备，这些设备通常会中断处理器。
·%DPC time
简述：指在实例间隔期间，处理器用在延缓程序调用（DPC）接收和提供服务的时间百分比，就是消耗在网络处理上的时间，该值越低越好。由于DPC是以特权模式执行的，DPC时间的百分比为特权时间百分比的一部分。
·Queue Length
简述:指跟踪服务器工作队列当前长度的计数器，该数值会显示出处理器瓶颈。队列长度持续大于2则表示可能出现处 理器拥塞。
·
Physical Disk
·%DiskTime
简述：指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。
正常值<10，此值过大表示耗费太多时间来访问磁盘，可考虑增加内存、更换更快的硬盘、优化读写数据的算法。若数值持续超过80 (此时处理器及网络连接并没有饱和)，则可能是内存泄漏。
参考值：
·CurrentDiskQueueLength
简述：读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。(磁盘数1.5-2倍)
参考值：
·Avg.Disk Queue
Length
Avg.Disk Read
QueueLength
Avg.Disk Write
QueueLength
Disk Read/sec
Disk Write/sec
简述：读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。
磁盘瓶颈判断公式：
每磁盘的I/O数=（读次数+（4*写次数））/磁盘个数。
如果计算出来的每磁盘的I/O数大于磁盘的处理能力，那么磁盘存在瓶颈。
参考值：
Avg.DiskQueue Length正常值<0.5，此值过大表示磁盘IO太慢，要更换更快的硬盘。
综合判断：
1、处理器队列堵塞判断方法：如果Processor queue length大于2，而处理器利用率一直很低，则存在处理器堵塞。
2、处理器瓶颈判断方法： 排除内存因素后，如果%processor time持续大于90%，并且%interrupt time的值持续大于15%，同时网卡和硬盘的值比较低，可以断定处理器负荷过重，无法满足业务增长需要，处理器是系统瓶颈点。
3. 监视内存不足的状况，可以通过 page/sec,Available Mbytes、page read/sec、page faults/sec等计数器的指标进行监控，还可以通过使用“页面交换”的频率来衡量。
“页面交换”是使用称为“页面”的单位，将固定大小的代码和数据块从RAM移动到磁盘的过程，从而释放暂时不使用的空间，这些页面文件就是操作系统用来虚拟内存的硬盘空面。操作系统对于虚拟内存主要设置两点，即内存页面文件的大小和页面文件存放的位置，内 存页面文件的大小就是设置虚拟内存最小和最大空间量，而页面位置则是设置虚拟内存使用哪个分区中的硬盘空间。
频繁的页面交换将降低系统性能，如果系统“页交换”频繁，说明内存不足。通过调优配置减少页交换，将显著提高系统响应速度。
4. 通过pages/sec指标判断是否存在内存问题，如果pages/sec持续高于几百，则有可能需要增加内存，以减少换页的需求，此时还应该进一步研究 页交换活动。如果pages/sec指标过高（几百），而硬盘数据流量不高（几百kb/s）则可确定是内存不足问题，如果pages/sec指标较高（几百），而此时硬盘数据流量也很高（几千KB /S），则可以判定是磁盘问题。
5.通过 available mbytes来判断是否存在严重内存泄漏问题，如果该值很小（<4M）,则说明计算机上总的内存可能不足，或者某个程序始终占用而没有释放内存，系统存在严重的内存泄漏问题。
6.如果页面读取操作速率page reads/sec指标的值很低，同时%disk time和avg.disk queue length的值却很高，则确定为磁盘瓶颈，但如果Avg.sidk queue length增加的同时page reads/sec页面读取速率指标并未降低，则确定为内存不足。
注：在run里面输入perfmon即可打 开本机监视器
判断CPU瓶颈,如果processor queue length显示的队列长度保持不变(>=2)并且处理器的利用率%Processor time超过90%,那么很可能存在处理器瓶颈.如果发现processor queue length显示的队列长度超过2,而处理器的利用率却一直很低,或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈. |
Full Scans/sec |
全表扫描，如果该值持续较大或偶尔较大，表示可能存在堆表扫描。 |
Number of Deadlocks/sec |
死锁的数量，应该始终保持为0。 |
Average Wait Time (ms) |
锁等待解除时间，平均>25ms，可能需要优化SQL |
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有