如何解决容器上的“container_memory_working_set_bytes”和“container_memory_rss”指标有什么区别
我需要监控在 kubernetes 集群上运行的容器内存使用情况。看了一些文章后有两个建议:“container_memory_rss”,“container_memory_working_set_bytes”
两个指标的定义都说了(来自 cAdvisor 代码)
- "container_memory_rss" : 匿名和交换缓存内存量
- “container_memory_working_set_bytes”:工作集内存量,包括最近访问的内存、脏内存和内核内存
我认为这两个指标都代表进程使用的物理内存上的字节大小。但是我的 grafana 仪表板中的两个值之间存在一些差异。
我的问题是:
- 两个指标有什么区别?
- 哪些指标更适合监控内存使用情况?一些帖子说两者都是因为这些指标之一达到了限制,然后该容器被 oom 杀死了。
解决方法
你说得对。我会尽量更详细地回答您的问题。
两个指标有什么区别?
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"`
Working Set 是此进程的工作集的当前大小(以字节为单位)。工作集是进程中线程最近触及的内存页的集合。
哪些指标更适合监控内存使用情况?有帖子说 两者都是因为这些指标之一达到了极限,那么 容器被 oom 杀死了。
如果您是 limiting the resource usage 的 Pod,那么您应该同时监控两者,因为如果它们达到特定资源限制,它们将导致 oom-kill。
我还推荐 this article,它显示了一个解释以下断言的示例:
您可能认为内存利用率很容易跟踪
container_memory_usage_bytes
,但是,该指标还包括
可以在内存下逐出的缓存(想想文件系统缓存)项目
压力。更好的指标是 container_memory_working_set_bytes
作为
这就是OOM杀手正在关注的。
编辑:
添加一些额外的来源作为补充:
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。