性能分析
性能结果分析是性能测试中的一个重要部分,同时也是一个难点。由于不同的软件系统,不同的性能指标,结果分析方法都是不一样的。需要具体问题具体分析。下面将阐述一些性能分析的方法与建议。
1 性能分析的目的
1)找出系统瓶颈(硬件、软件)
2)提出性能优化方案
3)达到合理的硬件和软件配置
4)使系统资源使用达到最大平衡
2 常见性能瓶颈征兆
在性能测试执行过程中,我们需要观察和了解系统的运行状态,如果出现以下征兆,则表示系统可能存在瓶颈。
1) 持续缓慢:应用程序一直特别慢,改变负载,对整体响应时间影响很少;
2) 随着时间推进越来越慢:负载不变,随着时间推进越来越慢,可能到达某个阈值,系统被锁定或出现大量错误而崩溃;
3) 随着负载增加越来越慢:每增加若干用户,系统明显变慢,用户离开系统,系统恢复原状;
4) 零星挂起或异常错误:可能是负载或某些原因,用户看到页面无法完成并挂起,无法消除;
5) 可预见的锁定:一旦出现挂起或错误,就加速出现,直到系统完全锁定。通常要重启系统才解决。
6) 突然混乱:系统一直运行正常,可能是一个小时或三天之后,系统突然出项大量错误或锁定。
3 性能数据解读建议
性能分析过程也是一个解读数据的过程,读懂了数据你就能知道问题出在何处。随着经验的累积将会很容易判断问题的根源,甚至在开发阶段就能对可能出现问题的点打预防针。
性能指标类型 |
标准 |
性能瓶颈征兆 |
分析工具 |
TPS及其波动范围 |
1.Tps符合性能目标 2.Tps轨迹波动平稳 |
1.TPS有明显的大幅波动,不稳定。例如TPS轨迹缓慢下降,缓慢上升后骤降,呈瀑布型,呈矩形,分时间段有规律的波动,无规律的波动等。这些TPS的波动轨迹反映出被测试的性能点存在性能瓶颈,需要性能测试工程师与开发工程师查找性能瓶颈的原因。 2. TPS轨迹比较平稳,但是也存在波动现象。该类波动不明显,很难直接确定是否存在性能瓶颈。我们需要根据其他指标来进行判断。 |
Jmeter/loadrunner |
响应时间 |
90%平均事务响应时间<性能目标 |
1.关注高峰负载时,用户操作响应时间; 2.关注数据库增量,对用户操作响应时间的影响。 |
Jmeter/loadrunner |
Web\DB服务器内存 |
|
1.很高的换页率 2.进程进入不活动状态; 3.交换区所有磁盘的活动次数过高; 4.过高的全局系统CPU利用率; 5.内存不够出错(out of memory errors) |
Nmon/top/vmstat |
WEB\DB服务器CPU |
合理使用的范围在60%至70% |
1.很慢的响应时间 2.CPU空闲时间为零 3.过高的用户占用CPU时间 4.过高的系统占用CPU时间 5.长时间的有很长的运行进程队列 |
Nmon/vmstat/top |
WEB\DB服务器磁盘I/O |
Iowait<30% |
1.过高的磁盘利用率; 2.太长的磁盘等待队列; 3.等待磁盘I/O的时间所占的百分率太高; 4.太高的物理I/O速率; 5.过低的缓存命中率; 6.太长的运行进程队列,但CPU却空闲; |
Nmon/sar/iostat |
Oracle数据库 |
|
1.缓存命中率小于0.90 2.top 10sql耗时高 Oracle数据库的分析和优化,是一门专门的技术,进一步的分析可查相关资料,也可以查看数据库性能分析工具AWR章节。 |
AWR |
4 如何定位性能问题
性能问题的定位排查过程比较复杂,可以采用“拆分问题,隔离分析”的方法进行分析,即逐步定位、从外到内、从表及里、逐层分解、隔离排除。以下分析顺序可供参考。
日志分析--->服务器硬件瓶颈---〉网络瓶颈(对局域网,可以不考虑)---〉服务器操作系统瓶颈(参数配置)---〉中间件瓶颈(参数配置,web服务器等)---〉数据库及应用瓶颈(SQL语句、数据库设计、业务逻辑、算法等)。
以上过程并不是每个分析中都需要的,要根据测试目的和要求来确定分析的深度。整个过程中,要配套使用一些健康工具和日志进行。如: JDK自带的Jconsole,或者JProfiler,来监控服务器性能,oracle的监控工具awr等,具体工具可以参考工具篇。
另外,做性能测试的时候,我们一定要确保瓶颈不要发生在自己的测试脚本和测试工具上。
基于上述思想的指导,在具体执行层面,可以参考如下分析过程:
首先,当我们系统有问题的时候,我们不要急于去调查我们代码,这个毫无意义。我们首要需要看的是操作系统的报告。看看操作系统的CPU利用率,看看内存使用率,看看操作系统的IO,还有网络的IO,网络链接数,等等。通过观察这些数据,我们就可以知道我们的软件的性能基本上出在哪里。比如:
1) 先看CPU利用率,如果CPU利用率不高,但是系统的Throughput和Latency上不去了,这说明我们的程序并没有忙于计算,而是忙于别的一些事,比如IO。(另外,CPU的利用率还要看内核态的和用户态的,内核态的一上去了,整个系统的性能就下来了。而对于多核CPU来说,CPU 0是相当关键的,如果CPU0的负载高,那么会影响其它核的性能,因为CPU各核间是需要有调度的,这靠CPU0完成)
2) 然后,我们可以看一下IO大不大,IO和CPU一般是反着来的,CPU利用率高则IO不大,IO大则CPU就小。关于IO,我们要看三个事,一个是磁盘文件IO,一个是驱动程序的IO(如:网卡),一个是内存换页率。这三个事都会影响系统性能。
3) 然后,查看一下网络带宽使用情况,在Linux下,你可以使用iftop,iptraf,ntop,tcpdump这些命令来查看。或是用Wireshark来查看。
4) 如果CPU不高,IO不高,内存使用不高,网络带宽使用不高。但是系统的性能上不去。这说明你的程序有问题,比如,你的程序被阻塞了。可能是因为等那个锁,可能是因为等某个资源,或者是在切换上下文。
通过了解操作系统的性能,我们才知道性能的问题,比如:带宽不够,内存不够,TCP缓冲区不够,等等,很多时候,不需要调整程序的,只需要调整一下硬件或操作系统的配置就可以了。具体配置项的调优,可以参考配置项调优参考章节。
接下来,我们需要使用性能检测工具,也就是使用某个Profiler来差看一下我们程序的运行性能。如:Java的JProfiler/TPTP/CodeProProfiler,GNU的gprof,IBM的PurifyPlus,Intel的VTune,AMD的接下来,我们需要使用性能检测工具,也就是使用某个Profiler来差看一下我们程序的运行性能。如:Java的JProfiler/TPTP/CodePro Profiler,GNU的gprof,IBM的PurifyPlus,Intel的VTune,AMD的CodeAnalyst,还有Linux下的OProfile/perf,后面两个可以让你对你的代码优化到CPU的微指令级别,如果你关心CPU的L1/L2的缓存调优,那么你需要考虑一下使用VTune。使用这些Profiler工具,可以让你程序中各个模块函数甚至指令的很多东西,如:运行的时间,调用的次数,CPU的利用率,等等。这些东西对我们来说非常有用。
我们重点观察运行时间最多,调用次数最多的那些函数和指令。这里注意一下,对于调用次数多但是时间很短的函数,你可能只需要轻微优化一下,你的性能就上去了(比如:某函数一秒种被调用100万次,你想想如果你让这个函数提高0.01毫秒的时间,这会给你带来多大的性能)。
使用Profiler有个问题我们需要注意一下,因为Profiler会让你的程序运行的性能变低,像PurifyPlus这样的工具会在你的代码中插入很多代码,会导致你的程序运行效率变低,从而没法测试出在高吞吐量下的系统的性能,对此,一般有两个方法来定位系统瓶颈:
1)在你的代码中自己做统计,使用微秒级的计时器和函数调用计算器,每隔10秒把统计log到文件中。
2)分段注释你的代码块,让一些函数空转,做Hard Code的Mock,然后再测试一下系统的Throughput和Latency是否有质的变化,如果有,那么被注释的函数就是性能瓶颈,再在这个函数体内注释代码,直到找到最耗性能的语句。
最后再说一点,对于性能测试,不同的Throughput会出现不同的测试结果,不同的测试数据也会有不同的测试结果。所以,用于性能测试的数据非常重要,性能测试中,我们需要观测试不同Throughput的结果。
4 常见性能问题参考
下面是整理收集的一些常见问题列表,不全,也许并不对,大家可以补充指正。
类别 |
常见性能问题 |
操作系统类 |
1. Sys的CPU使用率过高 2. User的CPU使用率过高,持续大于80%以上 3.可用物理内存不足导致内存溢出 4. 磁盘空间不足导致交易处理失败,性能下降 5. TCP/IP连接数限制导致用户请求失败 6.磁盘IO使用比较繁忙,持续大于70% |
中间件类 |
常用主流中间件:Tomcat、apache、nginx、Weblogic、Jboss等 1.线程不回收导致溢出,引发宕机 2.数据库连接池不释放导致溢出 3.JVM内存参数设置不合理,新生代过大或偏小 4.永久代设置过小,导致栈溢出 5.其它问题 |
应用程序类 |
1. 程序响应时间超长 2. JAVA程序内存溢出,内存中存放大量数据对象 3. JAVA程序循环嵌套过多,过于精细的查询条件,子查询间等待超时 4.程序中存在死循环引起线程死锁,导致CPU使用率达到100% 5.某些返回结果未定义处理方式,导致线程等待,不释放,CPU使用率高 |
数据库类 |
1.SGA分配不合理,需要具体情况具体分析 2.使用全表扫描 3.对于查询业务比较多的表,未建立索引,或建立的索引不合理,在索引列上使用IS NULL和IS NOT NULL 4.存在数据库死锁导致数据库连接超时或不释放。 5.存在过于复杂的计算,导致CPU、内存和IO使用率较高。 6. 数据库读写过于频繁,导致IO使用率比较高 |
其他问题 |
1.网络问题,被测试环境网络环境小于100M 2. 客户端问题等等
|