golang 项目，每隔几个月就 oom 一次，来不及打印内存占用，谁有好的排查方法啊？
ng001 · 2023-05-15 14:52:07 +08:00 · 2504 次点击这是一个创建于 560 天前的主题，其中的信息可能已经有所发展或是发生改变。
- 1.项目比较大，数万行代码，平稳运行几个月才突发一次 oom
- 2.从内存监控看，从 300M 到内存上限（ 12G ）仅用时 3s
- 3.起协程每秒监控内存，大内存时自动保存 pprof 内存占用，但发现在事发时来不及打印就 oom 了
第 1 条附言 · 2023-11-24 17:53:01 +08:00
好像有了结论，在这里记录下，希望能帮到人
原因
代码在多协程下命中了竞态条件 (Race Conditions)，在fasthttp.Clone(header)时，数组存在并发的读写，导致Clone时读到了一个超大值，申请了超大空间，瞬间OOM。
效果
消除竞态条件后已稳定运行1+月，期望别打脸
 |
1
mxT52CRuqR6o5 2023-05-15 14:55:01 +08:00
golang 没有那种程序崩溃时自动把内存 dump 到硬盘的工具吗？
|
 |
2
void00000 2023-05-15 15:01:05 +08:00
定时用 pprof dump ，硬盘上只保存最近 10 次 dump 记录，如果 oom ，就分析最近 10 次使用 pprof dump 的记录
|
 |
3
opengg 2023-05-15 15:19:16 +08:00 via Android
某个请求触发了大量申请内存吧？
拿真实流量，按二分法压一下，确定大概的范围。 |
 |
4
aw2350 2023-05-15 15:23:13 +08:00
最好罗列一下系统内使用了哪些第三方包，有可能是第三方包有 bug,导致堆栈溢出
|
 |
5
lysS 2023-05-15 15:23:52 +08:00
oom 不也有日志吗？
|
 |
6
676529483 2023-05-15 15:44:53 +08:00
网关看看请求日志
应用日志里面找找 oom 本来就很难排查，我们以前 oom 开会从头到尾 review ，找出来的也不对，最后没办法线上 debug ，终于找到第三方包引用 c 库导致的 |
 |
7
tiedan 2023-05-15 15:56:47 +08:00
排查一下 cgo
|
|
8
aw2350 2023-05-15 16:03:11 +08:00
排查一下系统有无加载数据到内存的操作，诸如导出数据，预加载、内存缓存等。一下子干到 12G 用时 3s,这么大的加载量看起来只能像是那种静态数据压到内存里去了
|
 |
9
lecher 2023-05-15 17:34:31 +08:00
启用 vm.overcommit_memory=1 ，系统将会在 OOM kill 时保留一份 core dump
触发后去查对应目录中拿当时的 core dump 文件 *.core 。跑 gdb 分析 |
 |
10
hefish 2023-05-15 18:10:08 +08:00
几个月一次，一年也有四五次。。。我觉着。。不是那种天问一号，神州系列的任务。。。就凑合着过吧。。哈哈
|
 |
11
sadfQED2 2023-05-15 19:18:26 +08:00 via Android  3
@hefish 哈哈哈，我们线上就是。刚开始发现问题，大家连夜排查，查了几天都查不出来，然后分给一个人单独排查。后来几个月了，也找不到原因，大家一合计，反正线上有自动重启，挂一台机器问题也不大，于是屏蔽报警就当解决了
|
 |
12
brookegas 2023-05-15 22:48:08 +08:00
1 、找一台内存 1G 的测试机压力测试一下，这样就不需要等几个月才 OOM
2 、将虚拟内存加到 100G ，这样 OOM 的时候有足够的反应时间来打印 |
Select Language