《性能瓶颈分析方法.docx》由会员分享，可在线阅读，更多相关《性能瓶颈分析方法.docx（6页珍藏版）》请在课桌文档上搜索。
1、性能瓶颈分析方法同一场景：1 .小用户量的状况下测试2 .大用户量状况下的测试分析的方法：整个系统架构分析，系统响应时间消耗，采用图表分析查看事务响应时间，通过事务摘要图分析事务响应时间，那个消耗最大（通过小用户量和大用户量的响应时间分析，查看那个事务响应时间最高），确定哪部分功能是性能的瓶颈，分析WindoWreSoUrCe图表，查看CPU使用下列计数器标识叩U瓶颈ProcessorInterruptsZsecProcessor%ProcessorTimeProcess（process）%ProcessorTimeSystemProcessorQueueLength通过它来确定是否硬件本身消
2、失瓶颈，或者进一步确定应当怎么去推断性能产生瓶颈的地方！下一步去推断进程，那个进程消耗CPU最高下边就有很多种状况需要你自己去推断，有可能是进程调用了的函数消耗了系统资源形成上边的问题，也有可能是后台数据库消失的问题（这个就要看你的系统配置是什么样的，比如你的db服务器和应用服务器都配置在一台机器上）性能产生瓶颈有很多地方，所以需要进一推断，是否是后台数据库的问题还有待分析，是那条语句导致的问题需要进一步分析推断。分析原则： 详细问题详细分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点） 查找瓶颈时按以下挨次，由易到难。服务器硬件瓶颈-网络瓶颈（对局域网，可以不考虑）-服务器操作
3、系统瓶颈（参数配置）-）中间件瓶颈（参数配置，数据库，Web服务器等）-）应用瓶颈（SQL语句、数据库设计、业务规律、算法等）注：以上过程并不是每个分析中都需要的，要依据测试目的和要求来确定分析的深度。对一些要求低的,我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。 分段排解法很有效分析的信息来源： 1依据场景运行过程中的错误提示信息 2依据测试结果收集到的监控指标数据一.错误提示分析分析实例：1Error:FailedtoconnecttoSerVer”10.10.10.30:8080”:10060ConnectionError:timedoutEr
4、ror:Server”10.10.10.30hasshutdowntheconnectionprematurely分析：A、应用服务死掉。（小用户时：程序上的问题。程序上处理数据库的问题）B、应用服务没有死（应用服务参数设置问题）例：在很多客户端连接WebIogiC应用服务器被拒绝，而在服务器端没有错误显示,则有可能是Weblogic中的SerVer元素的AcceptBacklog属性值设得过低。假如连接时收到COnneCtiOnrefUSed消息，说明应提高该值，每次增加25%C、数据库的连接（1、在应用服务的性能参数可能太小了2、数据库启动的最大连接数（跟硬件的内存有关）2Error:Pa
5、gedownloadtimeout（120seconds）hasexpired分析：可能是以下缘由造成 A、应用服务参数设置太大导致服务器的瓶颈 B、页面中图片太多 C、在程序处理表的时候检查字段太大多二.监控指标数据分析1 .最大并发用户数：应用系统在当前环境(硬件环境、网络环境、软件环境(参数配置)下能承受的最大并发用户数。在方案运行中，假如消失了大于3个用户的业务操作失败，或消失了服务器ShUtdOWn的状况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有消失这种现象的并发用户数。假如测得的最大并发用户数到达了性能要求，且各服务器资源状况良好，业
6、务操作响应时间也达到了用户要求，那么0K。否则，再依据各服务器的资源状况和业务操作响应时间进一步分析缘由所在。2 .业务操作响应时间： 分析方案运行状况应从平均事务响应时间图和事务性能摘要图开头。使用“事务性能摘要图，可以确定在方案执行期间响应时间过长的事务。 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？ 假如服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的缘由。假如网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题3 .服务器资源监控指标：内存：IUNIX资源监控中指标内存页交换速率(
7、Pagingrate),假如该值间或走高，表明当时有线程竞争内存。假如持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。4 Windows资源监控中，假如ProcessVPrivateBytes计数器和ProcessXWorkingSet计数器的值在长时间内持续上升，同时MemoryVAvailablebytes计数器的值持续降低，则很可能存在内存泄漏。内存资源成为系统性能的瓶颈的征兆：很高的换页率(highpageoutrate);进程进入不活动状态；交换区全部磁盘的活动次数可高；可高的全局系统CPU采用率；内存不够出错(OUtofmemoryerrors)处理器：1 UNIX资源监控(
8、WindoWS操作系统同理)中指标CPU占用率(CPUutilization),假如该值持续超过95%,表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。假如服务器专用于SQLSerVer,可接受的最大上限是80-85%合理使用的范围在60%至70%o2 Windows资源监控中，假如SystemProcessorQueueLength大于2,而处理器采用率(PrOCeSSorTime)始终很低，则存在着处理器堵塞。CPU资源成为系统性能的瓶颈的征兆：很慢的响应时间(Sk)Wresponsetime)CPU空闲时间为零(ZeropercentidleCPU)过高的用户占用CPU时间
9、(highpercentuserCPU)过高的系统占用CPU时间(highpercentsystemCPU)长时间的有很长的运行进程队列(Iargerunqueuesizesustainedovertime)磁盘I/O：IUNIX资源监控(WindoWS操作系统同理)中指标磁盘交换率(DiSkrate),假如该参数值始终很高，表明I/O有问题。可考虑更换更快的硬盘系统。3 Windows资源监控中，假如DiSkTime和Avg.DiskQueueLength的值很高，而PageReads/sec页面读取操作速率很低，则可能存在磁盘瓶径。I/O资源成为系统性能的瓶颈的征兆：过高的磁盘采用率(hi
10、ghdiskutilization)太长的磁盘等待队列(Iargediskqueuelength)等待磁盘I/O的时间所占的百分率太高(IargepercentageoftimewaitingfordiskI/O)太高的物理I/O速率:IargephysicalI/Orate(notsufficientinitself)过低的缓存命中率(IOWbuffercachehitratio(notsufficientinitself)太长的运行进程队列，但CPU却空闲(IargerunqueuewithidleCPU)4.数据库服务器：SQLServer数据库：ISQLSerVer资源监控中指标缓存点
11、击率(CaCheHitRatio),该值越高越好。假如持续低于80%,应考虑增加内存。2假如FUlISCans/sec(全表扫描/秒)计数器显示的值比1或2高，则应分析你的查询以确定是否的确需要全表扫描，以及SQL查询是否可以被优化。3 NumberOfDeadk)CkSsec(死锁的数量/秒)：死锁对应用程序的可伸缩性特别有害,并且会导致恶劣的用户体验。该计数器的值必需为0。4 LockRequestssec(锁恳求/秒)，通过优化查询来削减读取次数，可以削减该计数器的值。Oracle数据库：1假如自由内存接近于0而且库快存或数据字典快存的命中率小于0.90,那么需要增力USHARED_PO
12、OL_SIZE的大小。快存(共享SQL区)和数据字典快存的命中率：select(sum(pins-reloads)sum(pins)fromv$librarycache;select(sum(gets-getmisses)sum(gets)fromv$rowcache;自由内存select*fromv$sgastatwherename=,freememory,;2假如数据的缓存命中率小于0.90,那么需要力口大DB_BLOCK_BUFFERS参数的值(单位：块)。缓冲区高速缓存命中率：selectname,valuefromv$sysstatwherenamein(dbblockgets,consistentgets,physicalreads,);HitRatio=1-(physicalreads/(dbblockgets+consistentgets)3假如日志缓冲区申请的值较大，贝IJ应力口大LoG.BUFFER参数的值。日志缓冲区的申请状况：selectname,valuefromvSsysstatwherename=4redologspacerequests1;4假如内存排序命中率小于0.95,则应加大SORT_AREA_SIZE以避开磁盘排序。内存排序命中率：
