容器上的“container_memory_working_set_bytes”和“container_memory_rss”指标有什么区别

Question

我需要监控在 kubernetes 集群上运行的容器内存使用情况。读了一些文章后有两个建议：

container_memory_rss

，

container_memory_working_set_bytes

两个指标的定义都说了（来自cAdvisor代码）

• container_memory_rss

  ：匿名和交换缓存内存的数量

• container_memory_working_set_bytes

  ：工作集内存量，包括最近访问的内存、脏内存和内核内存

我认为这两个指标都代表进程使用的物理内存上的字节大小。但我的 Grafana 仪表板中的两个值之间存在一些差异。

我的问题是：

• 两个指标有什么区别？
• 哪些指标最适合监控内存使用情况？有些帖子说两者都是因为其中一个指标达到了限制，然后该容器被 OOM 杀死。

Answer 1

你是对的。我会尽力更详细地回答您的问题。

两个指标有什么区别？

container_memory_rss

等于

total_rss

文件中

/sys/fs/cgroups/memory/memory.status

的值：

// The amount of anonymous and swap cache memory (includes transparent
// hugepages).
// Units: Bytes.
RSS uint64 `json:"rss"`

匿名和交换缓存内存总量（包括透明大页），它等于

total_rss

文件中

memory.status

的值。这不应与真正的

resident set size

或 cgroup 使用的物理内存量混淆。

rss + file_mapped

将为您提供 cgroup 的常驻集大小。它不包括换出的内存。它确实包含来自共享库的内存，只要这些库中的页面实际上位于内存中。它确实包括所有堆栈和堆内存。

---

container_memory_working_set_bytes

（正如 Olesya 已经提到的）是

total usage

-

inactive file

。这是对无法驱逐的内存量的估计：

// The amount of working set memory, this includes recently accessed memory,
// dirty memory, and kernel memory. Working set is <= "usage".
// Units: Bytes.
WorkingSet uint64 `json:"working_set"`

工作集是该进程的工作集的当前大小（以字节为单位）。工作集是进程中线程最近接触的内存页面集。

---

哪些指标最适合监控内存使用情况？有的帖子说 都是因为这些指标之一达到了极限，那么 容器被 oom 杀死。

如果您限制 pod 的资源使用，那么您应该同时监控这两个容器，因为如果它们达到特定的资源限制，它们将导致 oom-kill。

我还推荐这篇文章，其中显示了一个解释以下断言的示例：

您可能认为可以轻松跟踪内存利用率

container_memory_usage_bytes

，但是，这个指标还包括 可以在内存下逐出的缓存（认为文件系统缓存）项目 压力。更好的指标是

container_memory_working_set_bytes

作为 这就是 OOM 杀手所关注的。

编辑：

添加一些额外的来源作为补充：

• 深入了解 Kubernetes 指标 — 第 3 部分容器资源指标

• #1744

• 了解 Kubernetes 内存指标

• Kubernetes 中的 Memory_working_set 与 Memory_rss，你应该监控哪一个？

• 管理容器资源

• c顾问代码

Answer 2

实际上这不是一个答案，而是对已接受答案的增强。以下注释适用于 cgroup v1，可能不适用于 cgroup v2。

container_memory_working_set_bytes

（正如 Olesya 已经提到的）是

total usage

-

inactive file

。这是对无法驱逐的内存量的估计：

第一句话是正确的，但是不能被驱逐注释不是真的：至少，

container_memory_working_set_bytes

包含了

total_active_file

呈现的值，可以通过以下方式驱逐：

1. 由于可用内存不足系统自动回收

2. echo 1/2/3 > drop_caches

   此问题提到，请参阅此链接了解值 1/2/3 的含义

3. echo 0 > memory.force_empty

   cgroup 文档第 5.1 节提到

因此，以下结论也可能不正确：

如果您限制 pod 的资源使用，那么您应该监控这两个容器，因为如果它们达到特定的资源限制，它们将导致 oom-kill。

container_memory_working_set_bytes

达到限制实际上可能不会导致 oom-kill，至少在我们的环境中没有发生 oom-kill。在我们的环境中，我们监测到

total_active_file

不断增加，因此

container_memory_working_set_bytes

不断增加，在

container_memory_working_set_bytes

达到极限后，由于内存回收，

total_active_file

下降到较低值，因此

container_memory_working_set_bytes

也下降到较低值value，pod一直在运行，没有被杀死。

实际上，关于 container_memory_working_set_bytes 指标已经存在两个问题（this 和

this

），但是都没有解决。在我们的环境中，由于上述错误警报，我们现在正在监视

container_memory_rss

而不是

container_memory_working_set_bytes

。