我需要监控在 kubernetes 集群上运行的容器内存使用情况。阅读一些文章后,有两个建议:“container_memory_rss”、“container_memory_working_set_bytes”
两个指标的定义都说了(来自 cAdvisor 代码)
我认为这两个指标都代表进程使用的物理内存上的字节大小。但是我的 grafana 仪表板中的两个值之间存在一些差异。
我的问题是:
最佳答案
你是对的。我将尝试更详细地解决您的问题。
What is the difference between two metrics?
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 size
混淆。或 cgroup 使用的物理内存量。 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"`
工作集是此进程的工作集的当前大小(以字节为单位)。工作集是进程中线程最近触及的内存页集。Which metrics are much proper to monitor memory usage? Some post said both because one of those metrics reaches to the limit, then that container is oom killed.
如果您是 limiting the resource usage对于您的 pod,您应该同时监视它们,因为如果它们达到特定的资源限制,它们将导致 oom-kill。
我也推荐 this article它显示了一个解释以下断言的示例:
You might think that memory utilization is easily tracked with
container_memory_usage_bytes
, however, this metric also includes cached (think filesystem cache) items that can be evicted under memory pressure. The better metric iscontainer_memory_working_set_bytes
as this is what the OOM killer is watching for.
编辑:
添加一些额外的来源作为补充:
关于kubernetes - 容器上的 “container_memory_working_set_bytes” 和 “container_memory_rss” 度量有什么区别,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/65428558/