关于压测结束后程序内存使用率不下降的问题记录

ancoa

已于 2022-06-19 13:23:18 修改

阅读量4.8k

点赞数 15

文章标签： java 经验分享

于 2022-06-19 03:22:22 首次发布

本文链接：https://blog.csdn.net/ancoa/article/details/125354061

版权

一、声明

这里只是简单记录一下遇到的问题、以及中间的处理手段、最后的处理结果及个人分析结论，受限于个人知识水平和工作经历，其中的处理手段和分析结论可能是错的，如果有人因此被误导，我很抱歉，所以请读文章时多加分辨。

二、结论

先说结论，由于以前对JVM以及Java垃圾回收认识的不足，所以理所当然认为：Java程序在短时间内处理大量任务时会申请使用大量的内存空间，而等任务处理完毕（或者是请求的任务变少时），会有大量的内存被虚拟机回收回来，回收回来的内存由于短期内不再被使用，所以虚拟机会将内存归还给操作系统。

实际上以上认知是错误的，或者是由于对JVM的版本及其垃圾回收机制认识片面（也可以说是错误）。要记住几点：1、Java的垃圾回收简单地可以认为Java自己去管理已经从系统获得的内存，将不再被使用的对象占用的内存回收。2、Java将回收回来的大片内存，如果短期内没有被接着使用，不能理所当然地认为会被释放归还给操作系统，还不还受JVM版本（直接和GC版本有关）、JVM的参数配置影响。

所以，当有人跑来跟你说，你们的程序执行完任务后，内存使用率还一直处于高水位不下降，是不是你们的程序有bug，这时候至少你可以心理有个底：有时候程序执行完任务后就是不会释放内存，然后一直高内存占用运行。

三、起因

最近测试域对我们系统做压力性能测试，简单说就是模拟用户操作页面然后以多个线程并发调用我们的接口。当然压测是有通过指标的，比如压测时cpu使用率不能超过60%，内存使用率不能超过80%，单接口吞吐量不能低于30次每秒。在做压测的过程中遇上了很多问题，领导指派我来跟进压测，遇到问题也要负责结局。

先说一下我们的应用环境：我们的应用是SpringBoot应用，部署于两个docker节点上，每个节点上给应用分配的cpu只有2核，内存也只有2GB。

期初，测试结果不理想，内存使用率飙升到80%以上，cpu使用率也有60%，但吞吐量却不到30。

我之前也没有做过这样的工作，很多时候我们遇到问题都会先从自身找问题，比如认为可能是我们的程序写得不够合理，导致某些实例可能会频繁创建、而且会大量占用了内存，所以内存不够用。因此我们检查了程序，将那些需要经常从数据库读出大量数据构建出大数据结构对象（比如人员、机构树形对象）操作换成读取缓存。修改程序后发现，问题依旧存在，那就不是程序本身的问题了。

当然，这期间我还和测试域的同事沟通，学会了使用Jemter、以及他们的测试流程，还简化了压测的方式。接口的吞吐量上不来，其中一个原因是测试方式的问题，比如同时对多个接口测试，接口1测试调用了3000次，接口2调用了3000次，接口3调用了3次，接口4调用了3次，接口5调用了3次，但计算接口2吞吐量的时候完全不考虑接口1的调用（接口3、接口4、接口5调用次数太少可以忽略不计），这其实不太合理，因为接口1调用3000次而不是调用了3次，这会直接拉低借口的吞吐量。所以，测试改进接口调用方式。

询问了组内技术比较强的晓波同学。他分析是由于可用内存不够导致虚拟机需要大量GC来腾出内存来给新任务，同时GC也加剧了CPU使用率，所以吞吐量上不来。

在修改接口测试方式的同时，我们这边也协调提升资源配置。最终，给每个节点分配8GB内存，同时设定-Xms2g -Xmx6g 。

我感觉这次应该没问题了。结果晚上接到测试的通知：吞吐量达标了，但压测之后查看资源监控，发现程序占用内存为83%没有回落，测试不通过。

要保证测试通过，需要保证吞吐量（这个已经达标）、cpu使用率（这个之后再验证吧，jemeter将线程组的线程数降低一点就可以降低cpu使用率，当然吞吐量也会降但能达标）、内存占用率（为什么会到83%呢？为什么之后不会降呢？）

以上就是本次面对的问题。

四、问题处理过程

1、没办法，硬着头皮上

工作好几年了，当没有实际地去分析和解决过相关问题，所以我面对以上问题也是没有半点头绪的。

但之前多少还是读过几页《深入虚拟机内幕》这本书，头脑中唯一知道的就是遇到和jvm、内存、垃圾回收的问题时要去使用top、ps、free、jps、jsata、map等命令去查看cpu、内存的使用状况，分析进程线程等等一大堆我没怎么听过、不熟悉、也不怎么会有的命令和分析技术。

我们的理解是，程序在空闲下来时就应该释放内存并归还给操作系统。

遇上这种事情必须自己上，感觉头很大。

2、艰难的尝试

没办法，那就花了几个小时再次去了解jstat、jmap命令。由于网路隔离，其他带图形化的分析工具也没法使用，只能用这几个命令。期初节点上没有安装jdk，也就有一个openjdk版本的jre，我只能再在上面安装一个openjdk8。由于有顾虑，认为可能再装一个jdk可能影响节点上需要使用jre运行的程序的执行，所以连安装jdk也是战战兢兢的，不过经过授权后放心地去干了。

当然中间输入的命令很多，做了很多事情，但最重要的是几个命令：

（1）top：查看java程序的进程号以及资源使用情况

我们的程序用了6.6GB空间，这个6.6/8约等于83%。

(2)ps -ef：查看进程号、启动参数等

(3)jmap：说实话，这个工具很有用，不过我虽然执行了，但不清楚怎么去分析；

(4)jstack:同上；

(5)jstat -gc 进程号：重点用这个来分析垃圾回收

比如以下就是我某次执行命令后copy出来的结果，然后自己做分析（分析过程很蹩脚，甚至之前连OC、OU什么含义我都不清楚只能再去查资料，大家忍受一下）

堆内存有6GB，但实际使用的有2.6GB。

3、陷入困境

结合以上这些数据结合我们的程序启动参数“-Xms2g -Xmx6g”，我们这里整理一下我们的已知的信息：

1、随着压力增大，我们的java程序的堆内存慢慢膨胀到6GB，也就是-Xmx6g全用上了。外加堆之外的600多MB内存，JVM共管理使用6.6GB内存。6.6GB约占整个节点内存的的83%。

2、压力测试后，JVM还是用着这6.6GB内存，但堆内存实际被使用的只有2.6GB。明明有空闲的内存，为什么你不释放？？？

而且，之后，我们做了很多压力测试，我们使用top命令来查看资源使用情况，使用的内存还是6.6GB。我想破了头也不知道它为什么没有任务了内存不降。

4、网上搜索

我尝试去联系以前的同事，问Java程序在任务压力减轻或者是没有任务时，是不是应该归还内存，结果他们都告诉我：“是的”。至于为什么我的程序没有归还，他们也不清楚，也帮不上什么忙。

同事、朋友帮不上，那就问问万能的百度吧

5、出现转机

我再百度上搜了很多内容，其中最关键条目是：“java压力测试后内存不释放”、“JVM最大堆内存不回落的原因”、“如何减少JVM中的已提交堆内存 ”、“JVM最大堆内存不下降”、“JVM需要归还多余的内存”、“请教为何JVM不把空闲内存归还给操作系统”、“查询jvm使用哪种垃圾回收器”、“UseParallelGC归还系统内存”

6、形成最初结论

我不知道碰了多少次壁，看了多少篇文章，最后意识到：JVM可能不会归还内存给操作系统。我参考了以下这些文章，得出结论，并向领导做了汇报：

https://www.jianshu.com/p/7893ff6c3324
https://exp.newsmth.net/topic/3c127cffb4c4f86e8b34a84cb295d8b1
https://blog.csdn.net/qq826654664jx/article/details/117222044
https://blog.csdn.net/qq_40378034/article/details/110677269
https://bbs.csdn.net/topics/392052589
https://www.itdaan.com/blog/2016/11/23/1efed2e6a4229e7892e586f6ce30ee8a.html
https://blog.csdn.net/qq_39630314/article/details/101345122
https://www.zhihu.com/question/357813017
https://www.pianshen.com/article/8937988907/

7、验证

领导问以上内容是谁说的，我没回复（都贴了连接了，那可定是是网上说的）。

他又问，有没有参数可以让内存从操作系统层面降下来。

我说有参数，不过需要试试来验证是否有效。

之后我们就抽时间验证了。

在程序启动参数里加了“-XX:MaxHeapFreeRatio=50”后，程序在进行压测的时候，使用top命令查看，程序最多使用了2.8GB内存，之后再没上涨过。

领导也关注这个事，他认为是加了这个参数后，JVM判定达不到扩容条件，所以对内存没有涨，所以内存使用率不会上涨。

最后，又在程序启动参数里加入MinHeapFreeRatio=40 MaxHeapFreeRatio=70（之前只是加入MaxHeapFreeRatio=50），再次做压力测试，程序最多只用2.8G内存。

8、问题处理结果

为了保证压测通过，所以在压测的环境里，程序启动参数加了MinHeapFreeRatio=40 MaxHeapFreeRatio=70，保证压测是内存使用率满足通过要求（内存使用率2.8除以8，肯定是低于80%的）。

另外，由于我们设定参数后，由于堆内存的使用低于设定的水平，我猜测没有进行缩容（即JVM将内存归还给操作系统）。

虽然加这个参数没有使处于高位的内存水平下降（因为加了参数后，内存就没有上升到6GB的70%，就别提缩容了），但能通过压力测试了，这个参数的使用效果也和我们预想的不一致。

五、再提结论

最后，领导也认同了我的汇报内容：1、JVM默认不会释放归还暂时不用的内存给操作系统（这个和我们理所当然的认为不一样），当然有参数可以使之“归还”。2、不同的JVM这方面有差异；3、JVM管理的内存堆内空间的使用率虽然下降，但在外面的操作系统看来，你这Java程序还在占用从我申请走的那块内存，没有还给我（所以，部分监控软件看来你的Java程序就是过度消耗了内存不释放，你的程序一定有问题）。

六、尾声

晓波看到大周末的我们的工作群里还有讨论记录，就想写一篇文章记录一下，他比较擅长技术和分析。看了聊天内容后就知道为原因了，写了篇博文让我去看，我说：“其实这个问题给知道症结的人来解决3分钟就有结论了；而我却什么都不知道，也从来没有研究过相关的内容，导致浪费了一两天时间。早知道应该让你来处理这个问题了”。

其实还是我没有好好提高自己，很多进本的知识都没有掌握。

以下是他的文章。《压测内存80%分析》，现在就去看看，多学习学习。