目录
- 背景
- 实践
- 堆内内存查看分析
- 堆外内存限制处理
- 修改jvm参数之后效果
- 进一步分析堆内占用高的业务代码
- 番外之mat分析查看内存对象值
- 参考文章
背景
-
线上服务目前使用了128G内存，然而在大部分时间里，内存占用都超过120G，甚至接近满载。这导致了服务不时出现崩溃的情况，我们可以从内核层面看到相关的kill命令。在提供的java应用占用内存截图中，我们可以看到大部分内存被Java应用占用，优化前的JVM参数仅设置了最大堆和最小堆（分别为100G），其他参数均为默认设置。Java应用占用的内存接近120G，这是导致服务崩溃的罪魁祸首
所有应用内存占用.png
Java应用内存占用.png 在进行了深入的JVM调优之后，我们成功地节省了高达60G的内存，并彻底解决了频繁发生的Full GC问题。现在，应用程序将能够更平稳地运行，同时减少了不必要的内存浪费和性能波动。这意味着更高的应用程序性能和更佳的客户体验，以及更稳定的业务连续性
实践
堆内内存查看分析
- jps -l查看java应用pid
-
jstat -gcutil pid 1000 20 每秒输出gc情况，输出20次，半天就有199次full gc了，每次时间平均10多秒
gc情况.png -
jmap -heap pid指令查看内存， 这里需要使用跟运行jvm一样的用户，比如我这边root用户运行的jvm，那么我也得用root用户查看
简单查看内存占用.png -
从简单查看内存占用截图，分析java年轻代老年代占用50-60G了，这部分随着接口的处理，老年代和年轻代还会涨
老年代增长趋势.png
年轻代增长趋势.png - 从之前优化Jvm参数经验来说，内存一直都很告的原因是堆内内存设置的过大(100G)，导致堆内回收年轻代和老年代比较晚，然后又有新的对象过来，导致整体内存占用比较大，最终就超过服务内存上限被系统kill掉
堆外内存限制处理
- 堆外内存主要用于一些需要大量数据操作或避免在Java堆内进行数据拷贝的场景，ByteBuffer.allocateDirect类似这种写法，或者netty都有可能堆外，这块可以考虑有些定时任务抽出去。避免那么大堆内和大堆外一起，就容易oom，Apache Commons Compress 库中的 Compressor 和 Decompressor 类使用了 DirectBuffer 类，该类是 Apache Commons IO 库中的一个类，提供了对堆外内存的访问
- 标准的jvm参数里面应该包含堆外，元数据空间限制，这里加上堆外，元数据空间限制，具体jvm参数设置为(按照这个配置之后生成的oom文件是hprof格式的):
-Xms49152m -Xmx49152m -XX:MaxGCPauseMillis=200 -XX:+UseG1GC -XX:MaxDirectMemorySize=1024m -XX:-OmitStackTraceInFastThrow -XX:MinHeapFreeRatio=30 -XX:MaxHeapFreeRatio=50 -XX:MetaspaceSize=1024m -XX:MaxMetaspaceSize=1024m -XX:MinMetaspaceFreeRatio=0 -XX:MaxMetaspaceFreeRatio=100 -XX:G1ReservePercent=15 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=64M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/xxx -Xloggc:/xxxxx/gc.log -XX:ParallelGCThreads=8 -XX:ConcGCThreads=8 -XX:+HeapDumpOnOutOfMemoryError
- 对比之前的jvm参数，增加了很多jvm参数，由之前使用的并行gc垃圾回收器改为G1垃圾回收器，增加堆外内存限制，元数据空间大小限制，以及减小最大最小堆，以使其及时回收对应内存，而不至于oom
-
这边测试过调小jvm堆到1G之后oom会生成对应hprof文件，默认就是hprof文件，命名是用pid后缀
oom生成对应hprof文件.png -
下载下来本地mat分析就能看到oom具体哪个对象占用大了，这边本地下载文件是用XShell下载的，这块java堆设置的比linux服务器内存小不少，生成oom的hprof文件也比较容易
mat分析oom文件.png
修改jvm参数之后效果
-
java占用的内存明显降低，运行也比较稳定，gc垃圾回收也正常，注意看着ps不包含堆外，ps命令查看的进程占用内存大小只包含了JVM进程使用的堆内存。堆外内存是JVM进程使用的系统内存，无法通过ps命令直接查看。要查看JVM进程使用的堆外内存，可以使用pmap等命令，对比nmt
修改jvm后运行一段时间.png -
gc停顿时间符合预期，gc停掉时间符合预期2截图显示没有full gc了
gc停掉时间符合预期.png
gc停掉时间符合预期2.png -
整体机器内存使用也比较稳定，不会到128G而被kill掉
整体机器使用内存.png
进一步分析堆内占用高的业务代码
- 使用jmap -dump:format=b,file=/my.hprof pid，因为dump下来有大几十G，本地机器内存才16G，要本地mat分析内存dump情况难度很高，这边就使用scp命令从线上环境拉去hprof文件到测试环境，因为测试环境上也是128G比较容易分析，不会像本地一样卡住
- 在测试环境安装mat linux使用MAT分析dump文件，然后使用分析命令
nohup ./mat/ParseHeapDump.sh my0923.hprof org.eclipse.mat.api:suspects org.eclipse.mat.api:overview org.eclipse.mat &
- 然后有几份zip文件不到1M的，下载到本地，解压浏览器打开
-
看到有个Map对象占用了20多个G，罪魁祸首就是分析2截图的map对象，这个功能是将数据几十万数据全表加载到内存，这么大的对象就算是内存运行map查询也不会太快，后面计划使用其他架构比如ES代替全表加载到内存的功能，整体内存占用还能下降不少
分析.png
分析2.png - 注意这里用linux服务器上mat分析只能分析大概，细致的还是要本地mat分析合适，所以本地机器内存更大会更容易分析些，这边下载大内存的hprof文件，可以考虑先zip，然后按照sz方法从服务器下载超过4g文件方法分析文件，到本地合并下载，因为xshell限制文件sz到4G
-
当然也可以利用linux大内存的服务mat分析后， 将生成好的文件逐个下下来，本地分析
mat生成.png
番外之mat分析查看内存对象值
- 顺带实践下实战总结｜一次访问Redis延时高问题排查与总结（续）用工具分析查看线上运行的内存对象值
-
dump下堆文件hprof后，打开mat，使用Histogram，搜索redis相关配置
堆分析.png -
选择"Merge ... Path to GC Root"->"exclude weak/soft references"，之后就可以看redis连接创建销毁数目了
堆分析2.png
堆分析3.png -
或者His展示时List Object右键，记得拉长一些
分析3.png
分析4.png
