container_memory_working_set_bytes与process_reside

Question

我希望了解container_memory_working_set_bytes与process_resident_memory_bytes与total_rss（container_memory_rss）+file_mapped以便更好地配备系统来警报OOM的可能性。这似乎违背了我的理解（现在让我感到困惑），因为如果一个容器/pod正在运行一个进程，执行用Go编写的编译程序。为什么两者之间的差异如此之大（几乎是10倍以上）container_memory_working_set_bytesprocess_resident_memory_bytes另外，和之间的关系在这里很奇怪，这是我没想到的，读完这里后container_memory_working_set_bytescontainer_memory_rss + file_mapped匿名和交换缓存内存的总量（它包括透明的大页面），它等于来自 memory.status 文件的total_rss值。这不应与 cgroup 使用的真实驻留集大小或物理内存量相混淆。rss + file_mapped将为您提供 c 组的常驻集大小。它不包括换出的内存。它确实包括来自共享库的内存，只要这些库中的页面实际上在内存中。它确实包括所有堆栈和堆内存。因此，总驻留集大小是此值如何小于在给定 c 组中运行的容器cgrouprss + file_mappedcontainer_working_set_bytes这让我觉得这个统计数据我是不正确的。以下是用于构建上图的 PROMQLprocess_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_filecontainer_working_set_in_bytes

和 之间的关系可以使用以下表达式进行总结container_memory_rsscontainer_working_sets

container_memory_usage_bytes = container_memory_cache + container_memory_rss

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

这就解释了为什么更高。container_working_set

编号 #1

编号 #2

Answer 2

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

这是否有助于理解图表？

在我$dayjob，我们遇到了各种不同的问题，即Go运行时外部的不同工具如何计数以及显示执行用Go编写的程序的进程的内存使用情况。
再加上Go在Linux上的GC实际上并没有将释放的内存页面释放到内核中，而只是疯狂地（2）它就是这样的页面，一个释放了大量内存的GC循环不会导致外部工具（通常是统计数据）所采用的“进程”RSS读数的任何明显变化。MADV_FREEcgroups

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

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