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如此之大（接近10倍）process_resident_memory_bytes

container_memory_working_set_bytes而且和之间的关系在这里很奇怪，这是我读完container_memory_rss + file_mapped之后没有想到的

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

因此，cgroup总驻留集大小是rss + file_mapped如何小于container_working_set_bytes给定 cgroup 中运行的容器的值的

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

以下是用于构建上图的 PROMQL

• process_resident_memory_bytes{container="sftp-downloader"}
• container_memory_working_set_bytes{container="sftp-downloader"}
• go_memstats_heap_alloc_bytes{container="sftp-downloader"}
• 容器_内存_映射_文件{容器=“sftp-downloader”} + 容器_内存_rss{容器=“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