golang 项目，每隔几个月就 oom 一次，来不及打印内存占用，谁有好的排查方法啊？

[ng001]

• 1.项目比较大，数万行代码，平稳运行几个月才突发一次 oom
• 2.从内存监控看，从 300M 到内存上限（ 12G ）仅用时 3s
• 3.起协程每秒监控内存，大内存时自动保存 pprof 内存占用，但发现在事发时来不及打印就 oom 了

[mxT52CRuqR6o5]

golang 没有那种程序崩溃时自动把内存 dump 到硬盘的工具吗？

[void00000]

定时用 pprof dump ，硬盘上只保存最近 10 次 dump 记录，如果 oom ，就分析最近 10 次使用 pprof dump 的记录

[opengg]

某个请求触发了大量申请内存吧？
拿真实流量，按二分法压一下，确定大概的范围。

[aw2350]

最好罗列一下系统内使用了哪些第三方包，有可能是第三方包有 bug,导致堆栈溢出

[lysS]

oom 不也有日志吗？

[676529483]

网关看看请求日志
应用日志里面找找
oom 本来就很难排查，我们以前 oom 开会从头到尾 review ，找出来的也不对，最后没办法线上 debug ，终于找到第三方包引用 c 库导致的

[tiedan]

排查一下 cgo

[aw2350]

排查一下系统有无加载数据到内存的操作，诸如导出数据，预加载、内存缓存等。一下子干到 12G 用时 3s,这么大的加载量看起来只能像是那种静态数据压到内存里去了

[lecher]

启用 vm.overcommit_memory=1 ，系统将会在 OOM kill 时保留一份 core dump
触发后去查对应目录中拿当时的 core dump 文件 *.core 。跑 gdb 分析

[hefish]

几个月一次，一年也有四五次。。。我觉着。。不是那种天问一号，神州系列的任务。。。就凑合着过吧。。哈哈

[sadfQED2]

@hefish 哈哈哈，我们线上就是。刚开始发现问题，大家连夜排查，查了几天都查不出来，然后分给一个人单独排查。后来几个月了，也找不到原因，大家一合计，反正线上有自动重启，挂一台机器问题也不大，于是屏蔽报警就当解决了

[brookegas]

1 、找一台内存 1G 的测试机压力测试一下，这样就不需要等几个月才 OOM
2 、将虚拟内存加到 100G ，这样 OOM 的时候有足够的反应时间来打印