【性能测试】混合业务场景TPS+内存溢出定位分析+调优和分析（详情）

---

前言

1、混合业务场景的TPS计算方式

TPS的计算
单业务与混合业务业务的基准测试场景构建
单业务测试
混合业务测试：登录-资料录入-发短信认证-核保
页面渲染+业务处理时间+思考时间=单次业务时间

5分钟内完成2000笔资料录入+发短信认证 计算平均并发（单位时间内平均能同时处理完成的录入+认证业务）
平均并发=（单次时间*业务量）/业务总时间
平均并发（5s*2000）/300=33
峰值并发=平均并发数+3*根号平均并发 =33+17=50

2、内存溢出问题定位和分析

1）堆内存溢出

稳定性压测一段时间后，jmeter报错，日志报java.lang.OutOfMemoryError.Java heap space。

用jmap -histo pid命令dump堆内存使用情况，查看堆内存排名前20个对象，看是否有自己应用程序的方法，从最高的查起，如果有则检查该方法是什么原因造成堆内存溢出。

如果前20里没有自己的方法，则用jmap -dump来dump堆内存，在用MAT分析dump下来的堆内存，分析导出内存溢出的方法。

4)如果应用程序的方法没有问题，则需要修改JVM参数，修改xms，xmx，调整堆内存参数，一般是增加堆内存。

2）栈内存溢出

稳定性压测一段时间后，jmeter报错，日志报Java.Lang.StackOverflowError。

修改jvm参数，将xss参数改大，增加栈内存。
栈溢出一定是做批量操作引起的，减少批处理数据量。

3）持久代溢出

稳定性压测一定时间后，日志报Java.Lang.OutOfMemoryError.PermGen Space。

这种原因是由于类、方法描述、字段描述、常量池、访问修饰符等一些静态变量太多，将持久代占满导致持久代溢出。
修改jvm配置，将XX:MaxPermSize=256参数调大。尽量减少静态变量。

4）线程死锁

容量测试压测一段时间后，LR报连接超时。
造成这种现象的原因很多，比如带宽不够，中间件线程池不够用，数据库连接池不够，连接数占满等都会造成连接不上而报超时错误。

jstack命令dump线程栈，搜索线程栈里有没有block，如果有的话就是线程死锁，找到死锁的线程，分析对应的代码。

5）数据库死锁

容量测试压测一段时间后，LR报连接超时。

造成这种现象的原因很多，比如带宽不够，中间件线程池不够用，数据库连接池不够，连接数占满等都会造成连接不上而报超时错误。

数据库日志中搜索block，能搜到block的话就是存在数据库死锁，找到日志，查看对应的sql，优化造成死锁的sql。

3、性能调优和分析-Fullgc问题分析

从上面图示可以直接看出：
从画黑线的位置，年轻代对象急剧增加，而且无法被回收掉。
无法回收的对象直接进了老年代，立刻触发了fullgc，一次gc之后，老年代空间被撑爆

从数据可以分析：
单次fullgc时间（fgc总时间/fgc次数）越来越长，从最初的300ms逐渐增加到接近1s一次
内存对象是突然增多的，时间很短，很有可能是代码出现了故障

从现象预判结果：
等到内存彻底无法回收之后，系统会返回 java heap space（堆内存溢出）

多次fullgc无法释放内存之后，系统会返回 GC overhead limit exceeded
系统会出现大范围宕机现象
单次fullgc200ms已经算是生产故障，1s一次的fullgc是严重的故障

从下图再引申出一个性能问题

这图上可以看出，swap空间已经开始使用，说明内存使用已经超出了swap比例，开始内存交换。
于是内存交换就会和fullgc问题产生叠加效应。

当fullgc执行的时候，需要先从swap里面把数据交换出来，结束之后再把数据交换进去。
多次gc之后，可能把swap直接撑爆了，然后触发系统的oomkiller杀进程。

完整版！企业级性能测试实战，速通Jmeter性能测试到分布式集群压测教程

下面是我整理的2025年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

人生最珍贵的不是终点站的奖杯，而是追梦路上那个永不放弃的自己。当你觉得撑不住时，请记住：每个伟大的故事都写在最艰难的章节之后。你的坚持，正在创造别人眼中的奇迹！

别被暂时的风雨模糊了双眼！那些让你流泪的磨练，正在雕刻更璀璨的未来。当别人选择放弃时，你的坚持就是胜利的宣言。向前奔跑吧，整个世界都在等待你的光芒绽放！