为什么Golang MADV_FREE有时会导致OOM？

golang学习网今天将给大家带来《为什么Golang MADV_FREE有时会导致OOM？》，感兴趣的朋友请继续看下去吧！以下内容将会涉及到等等知识点，如果你是正在学习Golang或者已经是大佬级别了，都非常欢迎也希望大家都能给我建议评论哈~希望能帮助到大家！

我们使用go1.12和k8s部署服务。在实际生产环境中，我们有一个项目一直OOM，直到容器被杀死。经过网上查，是因为Golang MADV_FREE ，后来我们设置为MADV_DONTNEED，问题解决了。

网上说是MADV_Free，意思是系统只有感受到压力的时候才释放内存。但是内存分配一直在发生，我们的其他服务都在同一个环境中。为什么没有发生OOM？

正确答案

嗯，我怀疑这样的问题是否适合 SO，因为它不太可能有简短的直接答案，不过，让我尝试一下。

首先要考虑的是，内核中的 OOM 杀手在内核发现内存不足时启动，只会找到内存消耗最高的进程 1 并将其关闭。 （我希望您谈论的是内核中的 OOM 杀手，而不是某些特定于 k8s 的服务或您内部开发的东西。）

然后让我们考虑已切换为使用 MADV_FREE 的 Go 1.12 release notes：

在 Linux 上，运行时现在使用 MADV_FREE 来释放未使用的内存。这样效率更高，但可能会导致报告的 RSS 更高。 内核会在需要时回收未使用的数据。 要恢复到 Go 1.11 行为 (MADV_DONTNEED)，请设置环境变量 GODEBUG=madvdontneed=1。

（强调我的。）

这意味着，如果使用 Go 1.12 编译的程序在某个标准负载下运行一段时间，然后相同的程序在相同负载下的相同时间段内运行，但 GODEBUG=madvdontneed =1 设置，RSS 的表观消耗（从外部观察）在第一种情况下将高于第二种情况。
重申一下，Go 内存管理器实际标记为 madvise(2) 的内存页数在两次运行期间大致相同，但由于使用这两种方式处理释放的页的语义不同，读数所使用的 RSS 会有所不同。不是实际的内存使用情况，而是 RSS 的读数。

这显然使得使用 MADV_FREE 将内存返回给操作系统的进程更有可能被 OOM 杀手选中。

话虽如此，我建议您实际上从不同的角度看待您的问题。 测量用 Go 编写并通过“库存”Go 实现构建的程序的内存消耗并非完全无用，而仅对捕捉一些明显的东西有用，例如多个 GC 扫描周期内的稳定内存增长，这可能是表明内存泄漏。 要实际评估真实的内存使用模式，您必须使用正在运行的程序的 Go 运行时提供的指标。 我试图详细说明这个here的原因。

所以我想说，你最好集中精力修复 OOM Killer 设置或类似的东西（请注意，可以使特定进程免受 OOM Killer 的影响）。

另请注意，您使用的是非常旧的不受支持版本的 Go， 在 Go 1.16 中，madvise has been reverted 的行为再次出现，因此它再次使用 MADV_DONTNEED。 也许现在是升级的好时机。

¹ 实际上比这更复杂，因为 OOM 杀手有一组启发式方法用于查找“资源占用者”，而内存消耗只是它考虑的指标之一。

今天关于《为什么Golang MADV_FREE有时会导致OOM？》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！