时间戳

首页 > 解决方案 > `container_memory_working_set_bytes` 指标和容器上的 OOM-killer 之间有什么关系？

linux - `container_memory_working_set_bytes` 指标和容器上的 OOM-killer 之间有什么关系？

问题描述

我试图找出并了解 OOM-killer 如何在容器上工作。

为了弄清楚这一点，我阅读了很多文章，我发现 OOM-killer 会杀死基于oom_score. 并且oom_score由oom_score_adj该进程的内存使用情况决定。

并且有两个指标container_memory_working_set_bytes，container_memory_rss来自 cAdvisor，用于监控容器的内存使用情况。

似乎container_memory_rssRSSoom_score内存container_memory_rss（

但是从下面的文章中：

更好的指标是container_memory_working_set_bytes因为这是 OOM 杀手所关注的。

我无法理解 OOM-killer 正在监视容器的工作集内存这一事实。我想我不明白容器上工作集内存的含义，即“总使用量 - 非活动文件”。

我在哪里可以找到参考资料？或者你能解释一下工作集内存和容器上的OOM-kill之间的关系吗？

标签： linuxkubernetesmemorycontainers

解决方案

如您所知，container_memory_working_set_bytes是：

工作集内存的数量，它包括最近访问的内存、脏内存和内核内存。因此，工作集是（小于或等于）</=“使用”。

正container_memory_working_set_bytes被用于 OoM 决策，因为它不包括可以在内存压力情况下被驱逐的缓存数据（Linux 页面缓存）。

所以，如果container_memory_working_set_bytes增加到极限，就会导致oomkill。

您会发现，当 Linux 内核检查可用内存时，它会调用vm_enough_memory()以找出潜在可用的页面数量。

然后当机器内存不足时，包括缓存在内的旧页面帧将被回收，但内核仍然可能会发现它无法释放足够的页面来满足请求。现在是调用out_of_memory()终止进程的时候了。为了确定要被杀死的候选进程，它使用oom_score.

因此，当工作集字节达到限制时，这意味着即使在回收包括缓存在内的旧页面之后内核也无法找到可用页面，因此内核将触发 OOM-killer 来终止进程。

您可以在 Linux 内核文档中找到更多详细信息：

推荐阅读