性能测试之如何分析CPU异常曲线

性能测试为保证软件质量起到重要作用,对于交易量较大的应用系统,性能测试更是一个必不可少的环节。

测试人员通常通过监测响应时间、吞吐量、应用服务器和数据库服务器的CPU及内存来衡量系统的性能是否达标,那么,在性能测试过程中,面对一些异常的指标数据,我们应该如何层层剥茧,找到问题产生的原因?

如何聚焦、解决性能问题?笔者本次将总结移动端性能测试的经验,与大家分享如何应对CPU异常曲线。

一、性能测试发现的问题

本次是针对移动端应用进行性能测试,性能测试的交易分别为查询交易1、申请交易1、申请交易2、查询交易2和查询交易3。

在对5支交易进行混合疲劳8小时测试过程中,发现应用服务器的CPU使用率曲线呈现规律性的异常现象:混合场景疲劳发压几小时后,CPU使用率陡增,直至发压结束,曲线如图1所示。

01e176b295db4daef69382f3359a4868.png

图1 应用服务器CPU曲线

二、问题分析过程

2d264c70d44c58235f0ad0f845701efa.png

图2 问题分析流程图

1.发现问题时,初步猜测是由于环境不稳导致了CPU陡增,再次进行混合8小时疲劳测试,发现测试结果和最初的结果一致,排除环境因素。

2. 查询XMeter的运行日志,发现有Java.lang.OutOfMemoryError: Java heap space的报错信息,进而对Heapdump文件进行分析,并未发现导致该问题的代码块。随后修改堆内存配置,由原来的1.5G改为2.5G,再次混合疲劳压测8小时,压测结果如图3所示。

68aac0145dc632b8c2e11cd318b3dadb.png

图3 应用服务器CPU曲线

压测结果显示:应用服务器的CPU使用率曲线开始陡增的时间较之前变长,堆内存为1.5G时,CPU使用率在发压开始2-3小时左右陡增,直至发压结束;堆内存为2.5G时,CPU使用率在发压开始5-6小时左右陡增,直至发压结束。

3. 项目组进一步验证环境的参数配置,将服务器由2C/4G扩容至2C/8G,增加数据库连接池数目和WAS线程数,再次进行混合疲劳压测,测试结果显示CPU仍然出现陡增现象,排除环境参数配置因素。

4. 测试人员对应用服务器CPU曲线、数据库服务器CPU曲线、TPS曲线和请求响应时间曲线进行综合分析,发现应用服务器CPU陡增的同时,数据库CPU和TPS曲线呈现下降趋势,平均响应时间曲线升高,因此初步将问题原因聚焦于应用服务器程序问题。

(1)请求响应时间

154fa8d6647189fee3d9df367e0c5263.png

图4 请求响应时间曲线

(2)请求吞吐量

394e2e39097c417e30baf4e315aca109.png

图5 请求吞吐量曲线

(3)数据库服务器CPU曲线

c1bfa39a215f128a4ee8a5273a55688d.png

图6 数据库服务器CPU曲线

分析native_stderr.log,发现JVM堆内存使用量不断升高,堆内存回收异常,存在内存泄漏:

8416e6d5255ce4e5f3edf6ebc5baa74a.png

图7 JVM堆内存使用量曲线

5. 在确认是程序问题之后,通过对不同的交易进行压测来定位导致问题的交易:

(1)移动端交易单独压测

由于陡增的时间节点是发压后3小时,分别对每支交易进行压测4小时,进而对不同的交易组合进行混合压测4小时,CPU陡增现象均未出现。

(2)PC端与移动端交易进行压测

① 由于5支交易中仅申请交易2是旧交易,因此对PC端的申请交易2单独进行疲劳压测8小时,发现JVM堆内存使用率曲线显示正常;

② 对PC端申请交易2,移动端:查询交易1、查询交易2、查询交易3这4支交易进行混合疲劳压测8小时,发现JVM堆内存使用率曲线显示正常;

③ 对PC端申请交易2,移动端:查询交易1、查询交易2、查询交易3、申请交易1这5支交易混合疲劳压测8小时,问题复现,测试结果如图8所示。

0dd80a1701c5804ec81f4d5d10be0fc3.png

图8 应用服务器CPU曲线

JVM堆内存使用量曲线如图9所示。

d7364c95b615717c3945714a00cfb5c9.png

图9 JVM堆内存使用量曲线

初步确认申请交易1导致该问题出现,随后对申请交易1单独进行疲劳压测8小时,问题复现,确认该交易存在问题,测试结果如图10所示。

b2339ffe1231e49e7eda44e7f604599b.png

图10 应用服务器CPU曲线

JVM堆内存使用量曲线如图11所示。

d8f81c2e322216a80cb07dab3fa91f26.png

图11 JVM堆内存使用量曲线

三、解决方案

项目组对申请交易1和申请交易2的代码进行单步调试,定位到出现内存问题的代码块,随后比对PC端和移动端交易代码,发现移动端交易代码未对申请单缓存数据进行清理,加入了清理缓存数据的方法后,再次对5支交易进行混合疲劳压测8小时,应用服务器的CPU曲线平稳,未出现陡增现象。

代码块采用了线程上下文方式对每笔申请单数据进行缓存,采用此种方法,需要用remove()方法对其进行清理,这样可以加速JVM的回收,否则,在高并发的情况下,会出现JVM堆内存使用量一直升高,堆内存回收异常的现象。

四、测试总结及反思

性能测试过程中,响应时间、吞吐量、CPU是衡量性能的关键指标,当响应时间、吞吐量符合通过准则时,并不意味着性能一定是正常的,还要关注CPU曲线是否正常。

1.及时查看相关的日志,如XMeter日志、Heapdump文件、java core文件和native_stderr.log文件,通过日志文件分析堆内存是否存在回收异常、内存泄漏或内存溢出等现象。

2. 问题复现的压测时间至少为8小时或8小时以上,本次性能测试中,问题复现的压测时间均为3-5小时,压测时间不足导致问题未能很好的复现。

3. 日志显示存在内存泄漏的现象后,要着重检查代码,而不应该持续的更改配置和参数。

4. 应及时对测试结果进行全面分析,包括应用服务器CPU曲线、数据库服务器CPU曲线、请求吞吐量和请求响应时间,这样更有助于快速定位问题来源。

5. 由于堆内存会在服务器重启之后进行清理,因此为了使每次测试都是从初始状态开始,测试之前应该重启服务器。

推荐阅读

阿里线上Bug排查命令&工具清单!必须收藏!

顶级辅助之测试左移与测试右移

测试经理:"抓个包都不会?回家种地得了!"

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值