十分钟学会排查线上JVM内存溢出

有风houpfchn:
内存飙升 直接线上生成dump风险很大吧，一般不建议生成dump

【回复】我最后说了挑一个业务低点哈 主要还是启动参数一定要在oom 时候dump 出来 反正小心为上
【回复】回复 @掉入二次元2333 : 我说的是内存飙升的场景,不是OOM的场景,注意审题,内存飙升不一定会OOM
【回复】回复 @掉入二次元2333 :感觉oom以后不会自动恢复了，注册中心会剔除异常节点，业务也不再会跑到这节点了，在这节点dump我觉得对业务[笑哭]没啥影响了
coder-001:
up对于内存告警的配置是 不准确的，一方面是百分比告警，这种适用于暴增场景，但是暴增可能也会由于数据的瞬时导入导出，gc没来得及回收等原因引起，gc回收以后内存使用率会立即降低的 更重要的是内存泄露，需要配置prometheus线性回归告警指标监控堆内存

【回复】回复 @美年达分达 :瞬时内存暴涨导致的oom其实更少见，一般内存泄露导致的会常见一些，堆内存在瞬时打满属于常见现象，比如flink任务，正常情况下内存就是在30-90%之间反复横跳，一般来说gc次数相比堆内存的瞬时使用率都要来的更有效
【回复】我理解不管是不是瞬时都是应该知晓 比如瞬时到了80预警 你知道了 然后你观察一下没问题 那就没问题 不应该是不告警吧 另外内存泄漏这个场景 线上环境很少有真实内存泄漏导致的oom 吧 除了某些视频人为制造的内存泄漏 一个应用几百个线程 一个线程泄漏个几k 问题不大。当然我这么说并不是我支持内存泄漏 我只是表达内存泄漏导致oom 还是挺难的
半步天堂入地狱:
所以说项目实际启动上线的时候，一定要执行出现oom自动生成dump文件的命令吗？（公司项目上次出现oom的时候，要我排查，但是找不到dump文件，根本无法分析[笑哭]，所以一直有这个疑问）

【回复】是呀 不然没快照只能猜了
源来氏作田:
@抓紧抬走它 这个排查内存溢出的讲的挺好

反复意识离线的求宝:
这个dump文件我记得文件存在的话，日志会提示文件已存在，然后没生成新文件，文件大小跟jvm的内存设置大小差不多

【回复】就是把当时jvm内存对象信息全部持久化到磁盘，当时jvm内存多大文件就有多大
小明鸣哥哥:
不会触发操作系统的oom把终端进程kill掉吗

【回复】回复 @美年达分达 :生产上没有处理过这样的问题[呲牙]，学到了
【回复】有可能 我这个设置的比较小所以os 还是有内存的 生产上如果容器内存不够可能会不断重启
张张张张志喜:
博主发的这个获取dump文件命令，我试了一直提示我参数有问题，我使用的是java8：jmap获取dump文件 jmap -dump:format=hprof,file=/usr/jdk/dumpfile.hprof 【pid】，然后我换成了这个命令：jmap -dump:file=/dumpfile.hprof 【pid】就可以，求解~~~

【回复】你的jdk 版本不支持这个吧 换一个gmc 的命令试试呢
【回复】使用jmap --help查看，只有-dump format=b ，这一个参数，也就是生成二进制的内容。
回屋龙沟咪:
gceasy这个网站能不能分析那个dump文件？

【回复】回复 @回屋龙沟咪 : dump文件中能看到连接池信息，以及你的数据库url、用户名、密码。
【回复】回复 @回屋龙沟咪 :就是会泄漏你的dump 文件呀 至于实际有什么影响 得看有心人有什么本事了[呲牙]那是我的知识盲区
【回复】回复 @美年达分达 :上传dump文件有什么影响？
努力打工的喵先森:
老哥，我领导要求我分析出代码里面那些东西内存占用过高。这该咋解。他说一定会有方法的只是我找不到。。