记一次JVM内存溢出排查过程
内存溢出排查
1. 频繁FullGC预警
1.1 频繁FullGC告警:
时间发生在2020-07-10(周五)晚上21:15分左右,本该收拾行囊下班,突然收到频繁FullGC预警消息,吓的菊花一紧,过一会收到接口探活告警,说明服务已经不可用了;
1.2 下线当前问题节点:
服务是3台节点部署,既然其中一台出现问题,在上层网关上将当前节点下线,保证用户的请求不会再打到当前节点;
1.3 年青代和老年代情况:
登录监控平台查看jvm的情况:
黄色线:老年代
蓝色线:年青化
在21:10左右时,就已经开始发生明显的频繁FullGC;
1.4 YGC次数和FGC次数:
登录监控平台查看jvm的情况:
蓝色:当前出问题节点的YGC总次数;
蓝色:当前出问题节点的FGC总次数;
1.4 年青代具体情况:
黄色:S0;
紫色:S1;
蓝色:Eden;
大概在21:10 - 21: 20这段时间一直在YGC
2. 排查原因
经过上面的分析,和上次遇到的频繁FGC问题不一样 上次的是突增,突然被内存被占满,而本次的是存在缓慢的增长过程,猜测程序可能做了大批量导出;
2.1 生成dump文件
查看是否生成dump文件,如果没有生成,手动通过: jmap -dump:live,format=b,file=dump.hprof 进程号;生成dump文件;
2.2 重启服务
既然内存快照保存下来了,就可以放心的重新启动服务;
2.3 查看后台操作日志
查看后台操作日志,发现用户对一张拥有2200W记录的表做了一次导出,但是导出的sql里面有id值,按道理说只会导出一条;也不会导致程序内存溢出啊;
2.4 分析dump文件
既然可疑的导出有明确指定id,不会造成大批量的数据被加载进服务,那只能分析dump文件
dump文件大约28G,分析套路和 记一次排查线上频繁FullGC 过程 一样;
最后分析出来三个zip文件,解析后查看index.html;
大概占了24.3G,查看详细的调用栈;
还是出在导出的问题上;
2.5 查看服务器日志
经过精心排查服务器日志发现,在用户跳转到查询列表时,在没有输入任何查询条件的情况下,点击过导出按钮,造成大量记录被加载进内存;
2.6 服务优化
1.导出的限制方面做控制;
2.大数据量导出考虑数据迁移到其它平台;
3.为什么全量导出的操作没有被记录到操作日志(待排查)
4.网关高耗时请求也考虑告警;
- 记一次JVM内存溢出造成的tomcat假死排查
- 一次学会,jvm内存不再溢出
- 记一次排查内存泄漏的过程
- 一次 Java 内存泄漏排查过程,涨姿势
- 一次关于Redis内存诡异增长的排查过程实战记录
- 记一次问题排查的过程-服务器内存问题
- 生产环境-jvm内存溢出-jprofile问题排查
- 问题排查之JVM内存溢出
- 一次 Java 内存泄漏排查过程,涨姿势
- JceSecurity/BouncyCastleProvider导致JVM内存溢出、CPU过高问题排查
- 阿里面试官说出内存溢出排查过程,我用了MAT和jvisualvm他对我点赞
- JVM - 内存溢出问题排查相关命令jcmd jmap
- (转载)一次 Java 内存泄漏排查过程,涨姿势
- 一次JVM中FullGC问题排查过程
- JVM调优——Java动态编译过程中的内存溢出问题
- 一次生产问题排查解决过程(小问题,大神请绕过)
- 添加IFrame导致内存溢出的解决过程(IE浏览器,目前发现了原因,还未解决)
- [z]TOMCAT内存_JVM参数设置解决溢出
- JBOSS4.2 JVM配置-主要解决内存溢出
- JVM学习笔记一 之 内存泄露与内存溢出