关于container_memory_working_set_bytes、process_resident_memory_bytes和total_rss之间的关联

大家好，我们又见面了啊~本文《关于container_memory_working_set_bytes、process_resident_memory_bytes和total_rss之间的关联》的内容中将会涉及到等等。如果你正在学习Golang相关知识，欢迎关注我，以后会给大家带来更多Golang相关文章，希望我们能一起进步！下面就开始本文的正式内容~

我希望了解以下关系

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 之间的关系在这里很奇怪，这是我读完之后没想到的

匿名和交换缓存内存总量（包括透明大页），它等于 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"}

正确答案

所以关系看起来是这样的

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

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

this 有助于理解图表吗？

在我的 $dayjob 中，我们遇到了各种不同的问题，即 go 运行时外部的不同工具如何计算和显示执行 go 编写的程序的进程的内存使用情况。
再加上linux上的go的gc实际上并没有将释放的内存页面释放到内核，而只是将这些页面释放为madv_free madvise(2)s，释放大量内存的gc周期不会导致读数发生任何明显的变化外部工具获取的“进程”rss（通常为 cgroups 统计信息）。

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

顺便说一句，内存统计信息的 nextgc 字段对于观察您是否为容器设置了内存限制非常有用，因为一旦读取达到或超过您的内存限制，容器中的进程肯定会最终被终止。被 oom_killer 击落。

以上就是《关于container_memory_working_set_bytes、process_resident_memory_bytes和total_rss之间的关联》的详细内容，更多关于的资料请关注golang学习网公众号！