尽管runtime.MemStats.Sys 较小，但 RSS 和 OOM 触发率较高

今日不肯埋头，明日何以抬头！每日一句努力自己的话哈哈~哈喽，今天我将给大家带来一篇《尽管runtime.MemStats.Sys 较小，但 RSS 和 OOM 触发率较高》，主要内容是讲解等等，感兴趣的朋友可以收藏或者有更好的建议在评论提出，我都会认真看的！大家一起进步，一起学习！

我有一个进程会慢慢消耗更多 ram，直到它最终达到其 cgroup 限制并被 oom 终止，我正在尝试找出原因。

奇怪的是，go 的运行时似乎认为没有使用太多 ram，而操作系统似乎认为使用了很多 ram。

具体来说，查看runtime.memstats（通过extvar包）我看到：

"alloc":51491072,
"totalalloc":143474637424,
"sys":438053112,
"lookups":0,
"mallocs":10230571,
"frees":10195515,
"heapalloc":51491072,
"heapsys":388464640,
"heapidle":333824000,
"heapinuse":54640640,
"heapreleased":0,
"heapobjects":35056,
"stackinuse":14188544,
"stacksys":14188544,
"mspaninuse":223056,
"mspansys":376832,
"mcacheinuse":166656,
"mcachesys":180224,
"buckhashsys":2111104,
"gcsys":13234176,
"othersys":19497592

但从操作系统的角度来看：

$ ps auxwf
user       pid %cpu %mem    vsz   rss tty      stat start   time command
root       178  0.0  0.0   3996  3372 pts/0    ss   17:33   0:00 bash
root       246  0.0  0.0   7636  2828 pts/0    r+   17:59   0:00  \_ ps auxwf
root         1  166  2.8 11636248 5509288 ?    ssl  17:24  57:15 app server -api-public

因此，oss 报告的 rss 为 5380 mib，但 memstats 中的 sys 字段仅显示 417 mib。我的理解是这些字段应该大致相同。

gc 正在运行，通过设置 godebug=gctrace=1,madvdontneed=1 确认。例如，我看到如下输出：

gc 6882 @2271.137s 0%: 0.037+2.2+0.087 ms clock, 3.5+0.78/37/26+8.4 ms cpu, 71->72->63 MB, 78 MB goal, 96 P

根据进程的不同，数字略有不同，但它们都是 <100 mb，而操作系统报告 >1gb（并且不断增长，直到最终 oom）。

madvdontneed=1 是在黑暗中拍摄的，但似乎没有什么区别。我不认为 madvise 参数是相关的，因为似乎不需要将内存返回给内核，因为 go 运行时认为它并没有使用太多内存。

什么可以解释这种差异？我是否没有正确理解这些字段的语义？是否存在会导致 rss 增长（以及最终 oom 终止）但不会增加 memstats.sys 的机制？

解决方案

这是由于 MADV_FREE（在 Go 的某些版本 - 1.12 到 1.15 中默认使用）计入 RSS，即使它可供系统重用。这可能会导致 Linux OOM 杀手选择具有大量 MADV_FREE 内存的进程进行杀死，因为 RSS 被人为地调高。

这个问题和Why Golang MADV_FREE leads to OOM sometimes?很相似

今天关于《尽管runtime.MemStats.Sys 较小，但 RSS 和 OOM 触发率较高》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！