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

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

两个指标的定义都说了(来自 cAdvisor 代码)

  • "container_memory_rss" :匿名和交换缓存内存的数量
  • “container_memory_working_set_bytes”:工作集内存量,包括最近访问的内存、脏内存和内核内存

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

我的问题是:

  • 两个指标有什么区别?
  • 哪些指标更适合监控内存使用情况?一些帖子说两者都是因为这些指标之一达到了限制,然后该容器被 oom 杀死了。

回答

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

两个指标有什么区别?

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 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 杀手正在关注的。

编辑:

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

  • 深入研究 Kubernetes 指标——第 3 部分容器资源指标

  • 第1744章

  • 了解 Kubernetes 内存指标

  • Kubernetes 中的 Memory_working_set 与 Memory_rss,你应该监控哪一个?

  • 管理容器资源

  • c顾问代码


以上是容器上的“container_memory_working_set_bytes”和“container_memory_rss”指标有什么区别的全部内容。
THE END
分享
二维码
< <上一篇
下一篇>>