性能需求和监控分析(冲突时的文件备份2013-08-06-09-44-17)

性能测试需求和监控分析性能测试需求分析的重要意义性能测试需求分析的正确性是整个性能测试工作的最基本前提

性能测试点的选取原则发生频率非常高的（例如：139邮箱核心业务系统中的登录、收发邮件等业务，它们在每天的业务总量中占到90%以上）关键程度非常高的（产品经理认为绝对不能出现问题的，如登录等）资源占用非常严重的（导致磁盘I/O非常大的，例如某个业务进行结果提交时需要向数十个表存取数据，或者一个查询提交请求时会检索出大量的数据记录）性能测试需求描述要求

准确如**系统必须在不超过10秒的响应时间内,处理20起登录任务。再如发邮件时间最大不超过5秒以及平均时间在2秒以内。一致用户和性能测试工程师对有关术语的理解要一致,如:并发用户数、在线用户数、注册用户数:特定性能测试的需求一定是有条件的。检查系统后台关键业务数据10G、操作数据量为20K,

1500个用户、500个并发用户运行的负载下，连续运行12小时过程中,业务操作是否满足性能需求。获取性能测试需求的方法开发相关文档相似项目性能需求业界公认标准用户使用模型二八原则服务访问日志工作中的性能测试需求我们得到的测试需求往往是这么描述的：这个系统能否支撑200万的vu（每天登录系统的人次）。言下之意是：按照目前的硬件性能和数量，系统能否支撑200万的vu。然而，我们了解的是吞吐量、响应时间等指标吞吐量：系统每秒能处理的请求数，这个指标从服务器的视角，表征系统容量响应时间：从请求发出到第一个字节返回所需要的时间，这个指标从用户的视角，表征系统响应速度。常见的性能需求如下WEB首页打开速度5s以下，web登陆速度15s以下。邮件服务支持50万个在线用户计费话单成功率达到99.999%以上。在100个并发用户的高峰期，邮箱的基本功能，处理能力至少达到10TPS系统能在高于实际系统运行压力1倍的情况下，稳定的运行12小时这个系统能否支撑100万的vu（每天登录系统的人次）工作中的性能测试需求怎么办：只能由我们根据经验，把200万vu转化成一系列的指标。响应时间：根据国外的一些资料，一般操作的响应时间为2，5，8秒，2秒内优秀，5秒内良好，8秒内可接受，其它一些特殊的操作，如上传，下载可以依据用户体验的情况，延长响应时间。吞吐量：可以根据已经上线的类似产品进行估计。或者，采用80/20原则进行估计。我们经常使用的是80/20原则。工作中的性能测试需求怎么办：只能由我们根据经验，把200万vu转化成一系列的指标。响应时间：根据国外的一些资料，一般操作的响应时间为2，5，8秒，2秒内优秀，5秒内良好，8秒内可接受，其它一些特殊的操作，如上传，下载可以依据用户体验的情况，延长响应时间。吞吐量：可以根据已经上线的类似产品进行估计。或者，采用80/20原则进行估计。我们经常使用的是80/20原则。工作中的性能测试需求

80/20原则，又称帕累托效应，比如，80%的社会财富掌握在20%的人手里。应用于测试：从vu计算吞吐量根据80/20原则，80%的用户会在20%的繁忙时间内登陆。则繁忙时间每秒大概会有（2000000*80%）/(24*3600*20%)=100个用户登陆，也就是说，登陆操作的吞吐量是100TPS工作中的性能测试需求虽然已经有了响应时间和吞吐量指标，但是测试需求还是不明确的。我们的测试目的是什么？是验证当前硬件和软件配置能否支撑200万vu？是测试当前的硬件和软件配置最多能支撑多少vu?

是帮助开发寻找性能瓶颈？工作中的性能测试需求根据我们的经验，开发的需求往往是这样的，^_^：首先，请你们验证能否支撑200万vu。如果不能支撑，请找一下性能瓶颈。主要性能瓶颈解决后，请估计能支撑多少vu，如果不到200w，请估计要加多少机器。如果能支撑200万，请再加压，看看达到300万vu的时候，系统的性能。这么一细化，需求基本明确了。性能测试案例分析SMTP发邮件峰值TPS按照139邮箱20000万注册用户，其中日活跃用户数为1.5%的规模计算：日活跃用户=20000*1.5%=300万日活跃用户人均每天发6封邮件，用户使用客户端收发邮件比例20%，则：每天发邮件投递量=300万*6*20%=360万封根据139邮箱业务模型表，每天忙时集中邮件系数0.15，邮件平均峰值系数2,则：峰值邮件量=3600000*0.15*2/3600=300封/秒性能测试案例分析去年全年处理“WEB登录”交易约100万笔，考虑到3年后交易量递增到每年200万笔。假设每年交易量集中在8个月，每个月20个工作日，每个工作日8小时，试采用80～20原理估算系统服务器高峰期“WEB登录”的交易吞吐量应达到怎样的一个处理能力200万/8=25万/月25万/20=1.25万/日1.25万*80%/(8*20%*3600)=1.74TPS性能监控-cpuCPU也是一种硬件资源，和任何其他硬件设备一样也需要驱动和管理程序才能使用，我们可以把内核的进程调度看作是CPU的管理程序，用来管理和分配CPU资源，合理安排进程抢占CPU，并决定哪个进程该使用CPU、哪个进程该等待。打工仔接受和完成多少任务并向老板汇报了（中断）；打工仔和老板沟通、协商每项工作的工作进度（上下文切换）；打工仔的工作列表是不是都有排满（可运行队列）；打工仔工作效率如何，是不是在偷懒（CPU利用率）。性能监控-cpu监控的两种方式

LR自带的性能结果分析

Liunx自带的监控命令-vmstat,mpstat,psCPU利用率，如果CPU有100％利用率，那么应该到达这样一个平衡：65％－70％UserTime，30％－35％SystemTime，0％－5％IdleTime；上下文切换，上下文切换应该和CPU利用率联系起来看，如果能保持上面的CPU利用率平衡，大量的上下文切换是可以接受的；可运行队列，每个可运行队列不应该有超过1－3个线程（每处理器），比如：双处理器系统的可运行队列里不应该超过6个线程。性能监控-cpu参数介绍：r，可运行队列的线程数，这些线程都是可运行状态，只不过CPU暂时不可用；b，被blocked的进程数，正在等待IO请求；in，被处理过的中断数cs，系统上正在做上下文切换的数目us，用户占用CPU的百分比sys，内核和中断占用CPU的百分比wa，所有可运行的线程被blocked以后都在等待IO，这时候CPU空闲的百分比id，CPU完全空闲的百分比性能监控-cpu双核的机器从上面的数据可以看出几点：interrupts（in）非常高，contextswitch（cs）比较低，说明这个CPU一直在不停的请求资源；usertime（us）一直保持在80％以上，而且上下文切换较低（cs），说明某个进程可能一直霸占着CPU；runqueue（r）在4个。性能监控-cpu从上面的数据可以看出几点：contextswitch（cs）比interrupts（in）要高得多，说明内核不得不来回切换进程；进一步观察发现systemtime（sy）很高而usertime（us）很低，而且加上高频度的上下文切换（cs），说明正在运行的应用程序调用了大量的系统调用（systemcall）；runqueue（r）在14个线程以上，按照这个测试机器的硬件配置（四核），应该保持在12个以内。性能监控-cpu

LR自带的性能结果分析%ProcessorTimeCPU利用率，该计数器最为常用，可以查看处理器是否处于饱和状态，如果该值持续超过95%，就表示当前系统的瓶颈为CPU，可以考虑增加一个处理器或更换一个性能更好的处理器。（参考值：<80%）l

%PriviliagedTimeCPU在特权模式下处理线程所花的时间百分比。一般的系统服务，进程管理，内存管理等一些由操作系统自行启动的进程属于这类l

%UserTime与%PrivilegedTime计数器正好相反，指的是在用户状态模式下（即非特权模式）的操作所花的时间百分比。如果该值较大，可以考虑是否通过算法优化等方法降低这个值。如果该服务器是数据库服务器，导致此值较大的原因很可能是数据库的排序或是函数操作消耗了过多的CPU时间，此时可以考虑对数据库系统进行优化。表示耗费CPU的数据库操作，如排序，执行aggregatefunctions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。l

%DPCTime处理器在网络处理上消耗的时间，该值越低越好。越低越好。在多处理器系统中，如果这个值大于50%并且Processor:%ProcessorTime非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。性能监控-内存虚拟内存（VirtualMemory）把计算机的内存空间扩展到硬盘，物理内存（RAM）和硬盘的一部分空间（SWAP）组合在一起作为虚拟内存为计算机提供了一个连贯的虚拟内存空间，好处是我们拥有的内存”变多了“，可以运行更多、更大的程序，坏处是把部分硬盘当内存用整体性能受到影响，硬盘读写速度要比内存慢几个数量级，并且RAM和SWAP之间的交换增加了系统的负担。介绍和性能监测有关的两个内核进程：kswapd和pdflush:kswapddaemon用来检查pages_high和pages_low，如果可用内存少于pages_low，kswapd就开始扫描并试图释放32个页面，并且重复扫描释放的过程直到可用内存大于pages_high为止。扫描的时候检查3件事：1）如果页面没有修改，把页放到可用内存列表里；2）如果页面被文件系统修改，把页面内容写到磁盘上；3）如果页面被修改了，但不是被文件系统修改的，把页面写到交换空间。pdflushdaemon用来同步文件相关的内存页面，把内存页面及时同步到硬盘上。比如打开一个文件，文件被导入到内存里，对文件做了修改后并保存后，内核并不马上保存文件到硬盘，由pdflush决定什么时候把相应页面写入硬盘，这由一个内核参数vm.dirty_background_ratio来控制，比如下面的参数显示脏页面（dirtypages）达到所有内存页面10％的时候开始写入硬盘

#/sbin/sysctl-nvm.dirty_background_ratio10性能监控-内存页面类型

Linux中内存页面有三种类型：Readpages，只读页（或代码页），那些通过主缺页中断从硬盘读取的页面，包括不能修改的静态文件、可执行文件、库文件等。当内核需要它们的时候把它们读到内存中，当内存不足的时候，内核就释放它们到空闲列表，当程序再次需要它们的时候需要通过缺页中断再次读到内存。Dirtypages，脏页，指那些在内存中被修改过的数据页，比如文本文件等。这些文件由pdflush负责同步到硬盘，内存不足的时候由kswapd和pdflush把数据写回硬盘并释放内存。Anonymouspages，匿名页，那些属于某个进程但是又和任何文件无关联，不能被同步到硬盘上，内存不足的时候由kswapd负责将它们写到交换分区并释放内存。性能监控-内存监控的两种方式

LR自带的性能结果分析

Liunx自带的监控命令-vmstat,top,psswpd，已使用的SWAP空间大小，KB为单位；free，可用的物理内存大小，KB为单位；buff，物理内存用来缓存读写操作的buffer大小，KB为单位；cache，物理内存用来缓存进程地址空间的cache大小，KB为单位；si，数据从SWAP读取到RAM（swapin）的大小，KB为单位；so，数据从RAM写到SWAP（swapout）的大小，KB为单位；bi，磁盘块从文件系统或SWAP读取到RAM（blocksin）的大小，block为单位；bo，磁盘块从RAM写到文件系统或SWAP（blocksout）的大小，block为单位。wa，所有可运行的线程被blocked以后都在等待IO，这时候CPU空闲的百分比性能监控-内存Cache：高速缓存，位于CPU与主内存间的容量较小但速度很高的存储器，指待写入磁盘的缓存数据。Cached值很大，说明缓存文件数很多，如果频繁访问到的文件被cached，磁盘读I/O就会小Buffer：缓冲区，一个用于存储速度不同步的设备或优先级不同的设备之间传输数据的区域，指已经从磁盘读取有待后续使用的缓存数据可用内存=系统free内存+buffers+cached性能监控-内存由上面的输出结果可以看到：●用做缓冲区（buff）和快速缓存（Cache）的物理内存不断地增加，而空闲的物理内存（free）不断地减少，证明系统中运行的进程正在不断地消耗物理内存。●已经使用的虚拟内存（swpd）不断增加，而且存在着大量的页面交换（si和so），证明物理内存已经不能满足系统需求，系统必须把物理内存的页面交换到磁盘中去。由此可以得到这样的结论：该主机上的物理内存已经不能满足系统运行的需要，内存已成为该系统性能的一个瓶颈。性能监控-内存

LR自带的性能结果分析

PageFaults/sec当处理器在内存中读取某一页出现错误时，就会产生缺页中断，也就是pageFault。如果这个页位于内存的其他位置，这种错误称为软错误，用TransitionFault/sec

来衡量；如果这个页位于硬盘上，必须从硬盘重新读取，这个错误成为硬错误。硬错误会使系统的运行效率很快将下来。PageFaults/sec这个计数器就表示每秒钟处理的错误页数，包括硬错误和软错误。l

PageReads/sec表示为了解决硬错误而从硬盘上读取的页数。为了解析对内存的引用，必须读取页文件的次数。阈值为>5.越低越好。大数值表示磁盘读而不是缓存读。l

Page/sec表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百，那么您应该进一步研究页交换活动。有可能需要增加内存，以减少换页的需求(你可以把这个数字乘以4k就得到由此引起的硬盘数据流量)。Pages/sec的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致l

AvailableMbytes剩余的可用物理内存，单位是兆字节（参考值：>=10%）用物理内存数.如果AvailableMbytes的值很小，则说明计算机上总的内存可能不足，或某程序没有释放内存。l

CatheBytes文件系统的缓存（默认为50%的可用物理内存）性能监控-IO监控的两种方式

LR自带的性能结果分析

Liunx自带的监控命令-iostat磁盘通常是计算机最慢的子系统，也是最容易出现性能瓶颈的地方，因为磁盘离CPU距离最远而且CPU访问磁盘要涉及到机械操作，比如转轴、寻轨等。访问硬盘和访问内存之间的速度差别是以数量级来计算的，就像1天和1分钟的差别一样。

I/O即输入/输出(Input/Output)，是在主存和外部设备(如磁盘驱动器、终端和网络)之间拷贝数据的过程。输入操作时从I/O设备拷贝数据到主存，而输出操作是从主存拷贝数据到I/O设备。性能监控-IOrrqm/s:每秒进行merge的读操作数目。即delta(rmerge)/swrqm/s:每秒进行merge的写操作数目。即delta(wmerge)/sr/s:每秒完成的读I/O设备次数。即delta(rio)/sw/s:每秒完成的写I/O设备次数。即delta(wio)/srsec/s:每秒读扇区数。即delta(rsect)/swsec/s:每秒写扇区数。即delta(wsect)/srkB/s:每秒读K字节数。是rsect/s的一半，因为每扇区大小为512字节。wkB/s:每秒写K字节数。是wsect/s的一半。avgrq-sz:平均每次设备I/O操作的数据大小(扇区)。即delta(rsect+wsect)/delta(rio+wio)avgqu-sz:平均I/O队列长度。即delta(aveq)/s/1000(因为aveq的单位为毫秒)。await:平均每次设备I/O操作的等待时间(毫秒)。即delta(ruse+wuse)/delta(rio+wio)svctm:平均每次设备I/O操作的服务时间(毫秒)。即delta(use)/delta(rio+wio)％util:一秒中有百分之多少的时间用于I/O操作，或者说一秒中有多少时间I/O队列是非空的。即delta(use)/s/1000(因为use的单位为毫秒)性能监控-IO1.如果rkb/s和wkb/s值很高，说明系统短时间内正在做大批量的数据读写操作.连续大量的IO操作一般出现在数据库应用系统中2.IOPS的效能,可用每秒读写I/O字节数除以每秒读写IOPS数得出,比如：rkB/s除以r/swkB/s除以w/s7200是140,15000是200,生产环境用的是1万转，所以是167生产用服务硬盘不会小于10000转的，所以不用考虑那么低转速的硬盘3.如果％util接近100％，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。4.Iostat命令输出await，await指：每一个IO请求的处理平均时间（单位是毫秒）。这里可以理解为I/O响应时间，一般系统I/O相应时间低于5秒钟，10秒钟比较大了。性能监控-IO

LR自带的性能结果分析

PhysicalDisk（磁盘）l

%DiskTime表示磁盘驱动器为读取或写入请求提供服务所用的时间百分比，PageReads/sec和%DiskTime及Avg.DiskQueueLength。如果页面读取操作速率很低，同时%DiskTime和Avg.DiskQueueLength的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。另外两个都比较适中，硬盘可能会是瓶颈。l

AverageDiskQueueLength表示磁盘读取和写入请求提供服务所用的时间百分比，可以通过增加磁盘构造磁盘阵列来提高性能（<=磁盘数的2倍）读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2倍。要提高性能，可增加磁盘。注意：一个RaidDisk实际有多个磁盘。不应当超过物理磁盘数量的2倍,正常值<0.5l

AverageDiskReadQueueLength表示磁盘读取请求的平均数l

AverageDiskwriteQueueLength表示磁盘写入请求的平均数l

AverageDisk

sec/Read磁盘中读取数据的平均时间，单位是秒l

AverageDisk

sec/Transer磁盘中写入数据的平均时间，单位是秒，一般来说，定义该值小于15ms最为优异，介于15-30ms之间为良好，30-60ms之间为可以接受，超过60ms则需要考虑更换硬盘或硬盘的RAID方式了性能监控-中间件中间件

tomcat，weblogic，jboss，Apache我们把Tomcat的调整可以分为两类来详细描述：调整非Tomcat组件，例如Tomcat运行的操作系统和运行Tomcat的java虚拟自身调整修改Tomcat自身的参数，调整Tomcat配置文件中的参数。性能监控-中间件

JAVA虚拟机性能优化通过命令行的方式改变虚拟机使用内存的大小。如下表所示有两个参数用来设置虚拟机使用内存的大小。参数描述-Xms<size>JVM初始化堆的大小-Xmx<size>JVM堆的最大值这两个值的大小一般根据需要进行设置。初始化堆的大小执行了虚拟机在启动时向系统申请的内存的大小。一般而言，这个参数不重要。但是有的应用程序在大负载的情况下会急剧地占用更多的内存，此时这个参数就是显得非常重要，如果虚拟机启动时设置使用的内存比较小而在这种情况下有许多对象进行初始化，虚拟机就必须重复地增加内存来满足使用。由于这种原因，我们一般把-Xms和-Xmx设为一样大，而堆的最大值受限于系统使用的物理内存。一般使用数据量较大的应用程序会使用持久对象，内存使用有可能迅速地增长。当应用程序需要的内存超出堆的最大值时虚拟机就会提示内存溢出，并且导致应用服务崩溃。因此一般建议堆的最大值设置为可用内存的最大值的80%。Tomcat默认可以使用的内存为128MB，在较大型的应用项目中，这点内存是不够的，需要调大。Windows下，在文件{tomcat_home}/bin/catalina.bat，Unix下，在文件{tomcat_home}/bin/catalina.sh的前面，增加如下设置：JAVA_OPTS='-Xms【初始化内存大小】-Xmx【可以使用的最大内存】'需要把这个两个参数值调大。例如：JAVA_OPTS='-Xms256m-Xmx512m'表示初始化内存为256MB，可以使用的最大内存为512MB。另外需要考虑的是Java提供的垃圾回收机制。虚拟机的堆大小决定了虚拟机花费在收集垃圾上的时间和频度。收集垃圾可以接受的速度与应用有关，应该通过分析实际的垃圾收集的时间和频率来调整。如果堆的大小很大，那么完全垃圾收集就会很慢，但是频度会降低。如果你把堆的大小和内存的需要一致，完全收集就很快，但是会更加频繁。调整堆大小的的目的是最小化垃圾收集的时间，以在特定的时间内最大化处理客户的请求。在基准560TD(E测试的时候，为保证最好的性能，要把堆的大小设大，保证垃圾收集不在整个基准测试的过程中出现。如果系统花费很多的时间收集垃圾，请减小堆大小。一次完全的垃圾收集应该不超过3-5秒。如果垃圾收集成为瓶颈，那么需要指定代的大小，检查垃圾收集的详细输出，研究垃圾收集参数对性能的影响。一般说来，你应该使用物理内存的80%作为堆大小。当增加处理器时，记得增加内存，因为分配可以并行进行，而垃圾收集不是并行的。性能监控-中间件

自身调整禁用DNS查询当web应用程序向要记录客户端的信息时，它也会记录客户端的IP地址或者通过域名服务器查找机器名转换为IP地址。DNS查询需要占用网络，并且包括可能从很多很远的服务器或者不起作用的服务器上去获取对应的IP的过程，这样会消耗一定的时间。为了消除DNS查询对性能的影响我们可以关闭DNS查询，方式是修改server.xml文件中的enableLookups参数值：Tomcat4<ConnectorclassName="org.apache.coyote.tomcat4.CoyoteConnector"port="80"minProcessors="5"maxProcessors="75"enableLookups="false"redirectPort="8443"acceptCount="100"debug="0"connectionTimeout="20000"useURIValidationHack="false"disableUploadTimeout="true"/>Tomcat5<Connectorport="80"maxThreads="150"minSpareThreads="25"maxSpareThreads="75"enableLookups="false"redirectPort="8443"acceptCount="100"debug="0"connectionTimeout="20000"disableUploadTimeout="true"/>除非你需要连接到站点的每个HTTP客户端的机器名，否则我们建议在生产环境上关闭DNS查询功能。可以通过Tomcat以外的方式来获取机器名。这样不仅节省了网络带宽、查询时间和内存，而且更小的流量会使日志数据也会变得更少，显而易见也节省了硬盘空间。对流量较小的站点来说禁用DNS查询可能没有大流量站点的效果明显性能监控-中间件

自身调整调整线程数另外一个可通过应用程序的连接器（Connector）进行性能控制的的参数是创建的处理请求的线程数。Tomcat使用线程池加速响应速度来处理请求。在Java中线程是程序运行时的路径，是在一个程序中与其它控制线程无关的、能够独立运行的代码段。它们共享相同的地址空间。多线程帮助程序员写出CPU最大利用率的高效程序，使空闲时间保持最低，从而接受更多的请求。Tomcat4中可以通过修改minProcessors和maxProcessors的值来控制线程数。这些值在安装后就已经设定为默认值并且是足够使用的，但是随着站点的扩容而改大这些值。minProcessors服务器启动时创建的处理请求的线程数应该足够处理一个小量的负载。也就是说，如果一天内每秒仅发生5次单击事件，并且每个请求任务处理需要1秒钟，那么预先设置线程数为5就足够了。但在你的站点访问量较大时就需要设置更大的线程数，指定为参数maxProcessors的值。maxProcessors的值也是有上限的，应防止流量不可控制（或者恶意的服务攻击），从而导致超出了虚拟机使用内存的大小。如果要加大并发连接数，应同时加大这两个参数。webserver允许的最大连接数还受制于操作系统的内核参数设置，通常Windows是2000个左右，Linux是1000个左右。在Tomcat5对这些参数进行了调整，请看下表：属性名描述maxThreadsTomcat使用线程来处理接收的每个请求。这个值表示Tomcat可创建的最大的线程数。acceptCount指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理。connnectionTimeout网络连接超时，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。minSpareThreadsTomcat初始化时创建的线程数。maxSpareThreads一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程最好的方式是多设置几次并且进行测试，观察响应时间和内存使用情况。在不同的机器、操作系统或虚拟机组合的情况下可能会不同，而且并不是所有人的web站点的流量都是一样的，因此没有一刀切的方案来确定线程数的值。性能监控-数据库监控的两种方式

LR自带的性能结果分析监控工具-sitecope，OracleEm，数据库快照工具数据库调优原则避免过多复杂的SQL脚本，减少系统的解析过程避免过多的无用的计算，例如：死循环避免浪费内存空间没有必要的SQL脚本，导致内存不足内存中计算和访问速度很快尽可能的减少磁盘的访问的数据量，该原则是PLSQL优化中重要思想。尽可能的减少磁盘的访问的次数，该原则是PLSQL优化中重要思想。性能监控-问题分析实例1

如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换(contextswitches/sec显示的上下文切换次数太高)那么就会占用大量的系统资源,如果系统的吞吐量降低并且CPU的使用率很高,并且此现象发生时切换水平在15000以上,那么意味着上下文切换次数过高.

从图的整体看.contextswitches/sec变化不大,throughout曲线的斜率较高,并且此时的contextswitches/sec已经超过了15000.程序还是需要进一步优化.性能监控-问题分析实例2判断CPU瓶颈如果processorqueuelength显示的队列长度保持不变(>=2)个并且处理器的利用率%Processortime超过90%,那么很可能存在处理器瓶颈.如果发现processorqueuelength显示的队列长度超过CPU核数的1-3倍,而处理器的利用率却一直很低,或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈.%processortime平均值大于95,processorqueuelength大于CPU核数的1-3倍.可以确定CPU瓶颈.此时的CPU已经不能满足程序需要.急需扩展.性能监控-问题分析实例3判断内存泄露问题内存问题主要检查应用程序是否存在内存泄漏,如果发生了内存泄漏,process\privatebytes计数器和process\workingset计数器的值往往会升高,同时avaiablebytes的值会降低.内存泄漏应该通过一个长时间的,用来研究分析所有内存都耗尽时,应用程序反应情况的测试来检验.图中可以