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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 549 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

第 1 条附言 · 356 天前

好像有了结论，在这里记录下，希望能帮到人

原因

代码在多协程下命中了竞态条件 (Race Conditions)，在fasthttp.Clone(header)时，数组存在并发的读写，导致Clone时读到了一个超大值，申请了超大空间，瞬间OOM。

效果

消除竞态条件后已稳定运行1+月，期望别打脸

oom

内存

来不及

起协

12 条回复 • 2023-05-15 22:48:08 +08:00

mxT52CRuqR6o5

2023-05-15 14:55:01 +08:00

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

void00000

2023-05-15 15:01:05 +08:00

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

opengg

2023-05-15 15:19:16 +08:00 via Android

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

aw2350

2023-05-15 15:23:13 +08:00

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

lysS

2023-05-15 15:23:52 +08:00

oom 不也有日志吗？

676529483

2023-05-15 15:44:53 +08:00

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

tiedan

2023-05-15 15:56:47 +08:00

排查一下 cgo

aw2350

2023-05-15 16:03:11 +08:00

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

lecher

2023-05-15 17:34:31 +08:00

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

hefish

2023-05-15 18:10:08 +08:00

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

sadfQED2

2023-05-15 19:18:26 +08:00 via Android

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

brookegas

2023-05-15 22:48:08 +08:00

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