🍅 点击文末小卡片，免费获取软件测试全套资料，资料在手，涨薪更快
一、性能问题分析流程
1、查看服务器的CPU、内存 、负载等情况，包括应用服务器和数据库服务器
2、查看数据库健康状态，数据库死锁、连接池不释放
3、查看项目日志（查看无报错现象）
4、查看jvm的gc等情况
二、内存溢出
1、堆内存溢出
现象：
（1）压测执行一段时间后，系统处理能力下降。这时用JConsole、JVisualVM等工具连上服务器查看GC情况，每次GC回收都不彻底并且可用堆内存越来越少。
（2）压测持续下去，最终在日志中有报错信息：java.lang.OutOfMemoryError.Java heap space。
排查手段：
（1）使用jmap -histo pid > test.txt命令将堆内存使用情况保存到test.txt文件中，打开文件查看排在前50的类中有没有熟悉的或者是公司标注的类名，如果有则高度怀疑内存泄漏是这个类导致的。
（2）如果没有，则使用命令：jmap -dump:live,format=b,file=test.dump pid生成test.dump文件，然后使用MAT进行分析。
（3）如果怀疑是内存泄漏，也可以使用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堆中分配内存外，操作系统本身也需要分配资源来创建线程。
因此，当线程数量达到一定程度以后，堆中或许还有空间，但是操作系统分配不出资源来了，就出现这个异常了。
解决方法：
（1）减少堆内存
（2）减少线程数量
（3）如果线程数量不能减少，则减少每个线程的堆栈大小，通过-Xss减小单个线程大小，以便能生产更多的线程。
三、CPU过高
1、us cpu过高
现象：
压测过程中，使用top命令查看系统资源占用情况，us cpu过高，超过50%以上。
排查手段：
（1）使用top命令是哪个进程消耗CPU高
（2）再找到CPU消耗高的线程：top -H -p 进程号
（3）把线程号转换成16进制：printf "%x\n" 线程号
（4）再用jstack命令分析这个线程是在干什么：jstack 进程号 | grep 16进制的线程号
（5）通过JProfiler的CPU Views视图的层层分析，可以清楚的找到造成CPU高的原因
2、Sy cpu过高
现象：
压测过程中，使用top命令查看系统资源占用情况，sy cpu过高，超过50%以上。
排查手段：
（1）首先查看磁盘繁忙程度、磁盘的队列（iostat、nmon）
（2）如果磁盘没有问题，则使用strace查看系统内核调用情况
四、TPS上不去
（一）网络带宽
在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。
（二）连接池
最大连接数太少，造成请求等待。连接池一般分为服务器中间件连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。
（三）垃圾回收机制
从常见的应用服务器来说，比如Tomcat，如果堆内存设置比较小，就会造成新生代的Eden区频繁的进行Young GC，老年代的Full GC也回收较频繁，那么对TPS也是有一定影响的，因为垃圾回收时通常会暂停所有线程的工作。
（四）数据库
高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引没有绑定变量，抑或没有主从分离、读写分离等，就会导致数据库事务处理过慢，影响到TPS。
（五）硬件资源
包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。
（六）压力机
比如Jmeter和Loadrunner，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就需要进行分布式压测来解决其单机负载的问题）。
（七）业务逻辑
业务解耦度较低，较为复杂，整个事务处理线被拉长也会导致TPS上不去。
（八）系统架构
比如是否有缓存服务，缓存服务器配置，缓存命中率、缓存穿透以及缓存过期等，都会影响到测试结果。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。
