吐血整理,性能测试常遇问题+解决方法,一文带你打通...
1、内存溢出1)堆内存溢出现象:压测执行一段时间后,系统处理能力下降。这时用JConsole、JVisualVM等工具连上服务器查看GC情况,每次GC回收都不彻底并且可用堆内存越来越少。压测持续下去,最终在日志中有报错信息:java.lang.OutOfMemoryError.Java heap space。
目录:导读
前言
1、内存溢出
1)堆内存溢出
现象:
压测执行一段时间后,系统处理能力下降。这时用JConsole、JVisualVM等工具连上服务器查看GC情况,每次GC回收都不彻底并且可用堆内存越来越少。
压测持续下去,最终在日志中有报错信息:java.lang.OutOfMemoryError.Java heap space。
排查手段:
使用jmap -histo pid > test.txt命令将堆内存使用情况保存到test.txt文件中,打开文件查看排在前50的类中有没有熟悉的或者是公司标注的类名,如果有则高度怀疑内存泄漏是这个类导致的。
如果没有,则使用命令:jmap -dump:live,format=b,file=test.dump pid生成test.dump文件,然后使用MAT进行分析。
如果怀疑是内存泄漏,也可以使用JProfiler连上服务器在开始跑压测,运行一段时间后点击“Mark Current Values”,后续的运行就会显示增量,这时执行一下GC,观察哪个类没有彻底回收,基本就可以判断是这个类导致的内存泄漏。
解决方式:优化代码,对象使用完毕,需要置成null。
2)永久代 / 方法区溢出
现象:压测执行一段时间后,日志中有报错信息:java.lang.OutOfMemoryError: PermGen space。
产生原因:由于类、方法描述、字段描述、常量池、访问修饰符等一些静态变量太多,将持久代占满导致持久代溢出。
解决方法:修改JVM参数,将XX:MaxPermSize参数调大。尽量减少静态变量。
3)栈内存溢出
现象:压测执行一段时间后,日志中有报错信息:java.lang.StackOverflowError。
产生原因:线程请求的栈深度大于虚拟机所允许的最大深度,递归没返回,戒者循环调用造成。
解决方法:修改JVM参数,将Xss参数改大,增加栈内存。栈内存溢出一定是做批量操作引起的,减少批处理数据量。
4)系统内存溢出
现象:压测执行一段时间后,日志中有报错信息:java.lang.OutOfMemoryError: unable to create new native thread。
产生原因:操作系统没有足够的资源来产生返个线程造成的。系统创建线程时,除了要在Java堆中分配内存外,操作系统本身也需要分配资源来创建线程。因此,当线程数量大到一定程度以后,堆中或许还有空间,但是操作系统分配不出资源来了,就出现这个异常了。
解决方法:
减少堆内存;
减少线程数量;
如果线程数量不能减少,则减少每个线程的堆栈大小,通过-Xss减小单个线程大小,以便能生产更多的线程。
2、CPU过高
1)us cpu高
现象:压测过程中,使用top命令查看系统资源占用情况,us cpu过高,超过50%以上。
排查手段:
使用top命令是哪个进程消耗CPU高
再找到CPU消耗高的线程:top -H -p 进程号
把线程号转换成16进制:printf “%x\n” 线程号
再用jstack命令分析这个线程是在干什么:jstack 进程号 | grep 16进制的线程号
通过JProfiler的CPU Views视图的层层分析,可以清楚的找到造成CPU高的原因
2)sy cpu高
现象:压测过程中,使用top命令查看系统资源占用情况,sy cpu过高,超过50%以上。
排查手段:
首先查看磁盘繁忙程度、磁盘的队列(iostat、nmon)
如果磁盘没有问题,则使用strace查看系统内核调用情况
3、TPS上不去
1)网络带宽
在压力测试中,有时候要模拟大量的用户请求,如果单位时间内传递的数据包过大,超过了带宽的传输能力,那么就会造成网络资源竞争,间接导致服务端接收到的请求数达不到服务端的处理能力上限。
2)连接池
最大连接数太少,造成请求等待。连接池一般分为服务器中间件连接池(比如Tomcat)和数据库连接池(或者理解为最大允许连接数也行)。
3)垃圾回收机制
从常见的应用服务器来说,比如Tomcat,如果堆内存设置比较小,就会造成新生代的Eden区频繁的进行Young GC,老年代的Full GC也回收较频繁,那么对TPS也是有一定影响的,因为垃圾回收时通常会暂停所有线程的工作。
4)数据库
高并发情况下,如果请求数据需要写入数据库,且需要写入多个表的时候,如果数据库的最大连接数不够,或者写入数据的SQL没有索引没有绑定变量,抑或没有主从分离、读写分离等,就会导致数据库事务处理过慢,影响到TPS。
5)硬件资源
包括CPU(配置、使用率等)、内存(占用率等)、磁盘(I/O、页交换等)。
6)压力机
比如Jmeter和Loadrunner,单机负载能力有限,如果需要模拟的用户请求数超过其负载极限,也会间接影响TPS(这个时候就需要进行分布式压测来解决其单机负载的问题)。
7)业务逻辑
业务解耦度较低,较为复杂,整个事务处理线被拉长也会导致TPS上不去。
8)系统架构
比如是否有缓存服务,缓存服务器配置,缓存命中率、缓存穿透以及缓存过期等,都会影响到测试结果。
4、性能问题分析流程
查看服务器的CPU、内存 、负载等情况,包括应用服务器和数据库服务器
查看数据库健康状态,数据库死锁、连接池不释放
查看项目日志(查看无报错现象)
查看jvm的gc等情况
下面是我整理的2024年最全的软件测试工程师学习知识架构体系图 |
一、Python编程入门到精通
二、接口自动化项目实战
三、Web自动化项目实战
四、App自动化项目实战
五、一线大厂简历
六、测试开发DevOps体系
七、常用自动化测试工具
八、JMeter性能测试
九、总结(尾部小惊喜)
在追逐梦想的路上,不断奋斗,不停努力,即使艰难险阻重重,也要坚定前行,因为只有坚持才能谱写属于自己的壮丽篇章。
不论前路多艰辛,只要心怀希望,坚持不懈,终将迎来辉煌;每一份努力都是变得更强大的过程,坚持不懈才能书写精彩人生。
在人生的舞台上,每一次的努力都是闪耀的光芒,坚持不懈,才能超越自我,绽放出属于自己的辉煌。
开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!
更多推荐
所有评论(0)