时间戳

首页 > 解决方案 > 容器上的“container_memory_working_set_bytes”和“container_memory_rss”指标有什么区别

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

问题描述

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

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

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

我的问题是：

标签： kubernetesmemorycontainersmonitoring

解决方案

你说的对。我将尝试更详细地解决您的问题。

两个指标有什么区别？

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_rssfrom memory.statusfile 的值。这不应与resident set sizecgroup 使用的真实内存量或物理内存量相混淆。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 杀手所关注的。

编辑：

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

推荐阅读