这是一个创建于 887 天前的主题，其中的信息可能已经有所发展或是发生改变。
- 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