container_memory_working_set_bytes 与 process_resident_memory_bytes 和 total_rss 的关系

Question

我正在寻找了解的关系

container_memory_working_set_bytes vs process_resident_memory_bytes vs total_rss (container_memory_rss) + file_mapped 以便更好地配备警报系统OOM 的可能性。

考虑到 如果容器/pod 正在运行单个进程执行用 Go 编写的编译程序，这似乎与我的理解不符（这让我现在感到困惑）。

为什么container_memory_working_set_bytes 与process_resident_memory_bytes 之间的差异如此之大（将近10 倍）

还有container_memory_working_set_bytes和container_memory_rss + file_mapped之间的关系在这里很奇怪，是我没想到的，看了here之后

匿名和交换缓存内存的总量（包括透明的hugepages），它等于memory.status文件中total_rss的值。这不应与真正的驻留集大小或 cgroup 使用的物理内存量相混淆。 rss + file_mapped 将为您提供 cgroup 的常驻集大小。它不包括被换出的内存。只要这些库中的页面实际上在内存中，它就包含来自共享库的内存。它确实包括所有堆栈和堆内存。

所以cgroup的总驻留集大小是rss + file_mapped对于在给定cgroup中运行的容器，这个值怎么小于container_working_set_bytes

这让我觉得这些统计数据不正确。

以下是用于构建上图的 PROMQL

• process_resident_memory_bytes{container="sftp-downloader"}
• container_memory_working_set_bytes{container="sftp-downloader"}
• go_memstats_heap_alloc_bytes{container="sftp-downloader"}
• container_memory_mapped_file{container="sftp-downloader"} + container_memory_rss{container="sftp-downloader"}

Answer 1

所以关系似乎是这样的

container_working_set_in_bytes = container_memory_usage_bytes - total_inactive_file

container_memory_usage_bytes顾名思义是指容器使用的总内存（但由于它还包括文件缓存，即操作系统可以在内存压力下释放的inactive_file）减去inactive_file得到container_working_set_in_bytes

container_memory_rss 和container_working_sets 之间的关系可以用下面的表达式来概括

container_memory_usage_bytes = container_memory_cache + container_memory_rss 

缓存反映存储在当前缓存在内存中的磁盘上的数据。它包含活动+非活动文件（如上所述）

这解释了为什么container_working_set 更高。

参考#1

参考#2

Answer 2

不是一个真正的答案，但仍然是两个不同的点。

this 是否有助于理解图表？

在我的 $dayjob 中，我们遇到了各种不同的问题，即 Go 运行时外部的不同工具如何计算和显示执行用 Go 编写的程序的进程的内存使用情况。
再加上 Go 在 Linux 上的 GC 实际上并没有将释放的内存页面释放到内核，而只是 madvise(2)s 表明这些页面是 MADV_FREE，一个释放大量内存的 GC 循环不会导致任何外部工具（通常是cgroups stats）获取的“进程”RSS 读数发生显着变化。

因此，我们导出了我们自己的指标，这些指标是通过在任何用 Go 编写的主要服务中定期调用 runtime.ReadMemStats（和 runtime/debug.ReadGCStats）获得的——借助专门为此编写的简单包。这些读数反映了 Go 运行时关于其控制的内存的真实想法。

顺便说一句，如果您为容器设置了内存限制，内存统计信息的NextGC 字段非常有用，因为一旦该读数达到或超过您的内存限制，容器中的进程肯定注定要最终被 oom_killer 击落。