容器上的“container_memory_working_set_bytes”和“container_memory_rss”指标有什么区别
What is the difference between “container_memory_working_set_bytes” and “container_memory_rss” metric on the container
我需要在 kubernetes 集群上监控我的容器内存使用情况 运行。阅读一些文章后有两个建议：“container_memory_rss”、“container_memory_working_set_bytes”
两个指标的定义都说了（来自cAdvisor代码）
- "container_memory_rss" : 匿名和交换缓存内存的数量
- "container_memory_working_set_bytes"：工作集内存量，这包括最近访问的内存、脏内存和内核内存
我认为这两个指标都表示进程使用的物理内存的字节大小。但是我的 grafana 仪表板中的两个值之间存在一些差异。
我的问题是：
- 两个指标有什么区别？
- 哪些指标更适合监控内存使用情况？一些 post 说两者都是因为其中一个指标达到了限制，然后那个容器被 oom 杀死。
你是对的。我会尝试更详细地回答您的问题。
What is the difference between two metrics?
container_memory_rss 等于 /sys/fs/cgroups/memory/memory.status 文件中 total_rss 的值：
// The amount of anonymous and swap cache memory (includes transparent
// hugepages).
// Units: Bytes.
RSS uint64 `json:"rss"`
匿名和交换缓存内存总量（包括透明大页面），等于 memory.status 文件中 total_rss 的值。这不应与真正的 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 是此进程的工作集的当前大小（以字节为单位）。 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.
如果您的 pods 是 limiting the resource usage，那么您应该监控两者，因为如果它们达到特定的资源限制，它们将导致 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 is container_memory_working_set_bytes as
this is what the OOM killer is watching for.
编辑：
添加一些额外的来源作为补充：
我需要在 kubernetes 集群上监控我的容器内存使用情况 运行。阅读一些文章后有两个建议：“container_memory_rss”、“container_memory_working_set_bytes”
两个指标的定义都说了（来自cAdvisor代码）
- "container_memory_rss" : 匿名和交换缓存内存的数量
- "container_memory_working_set_bytes"：工作集内存量，这包括最近访问的内存、脏内存和内核内存
我认为这两个指标都表示进程使用的物理内存的字节大小。但是我的 grafana 仪表板中的两个值之间存在一些差异。
我的问题是：
- 两个指标有什么区别？
- 哪些指标更适合监控内存使用情况？一些 post 说两者都是因为其中一个指标达到了限制，然后那个容器被 oom 杀死。
你是对的。我会尝试更详细地回答您的问题。
What is the difference between two metrics?
container_memory_rss 等于 /sys/fs/cgroups/memory/memory.status 文件中 total_rss 的值：
// The amount of anonymous and swap cache memory (includes transparent
// hugepages).
// Units: Bytes.
RSS uint64 `json:"rss"`
匿名和交换缓存内存总量（包括透明大页面），等于 memory.status 文件中 total_rss 的值。这不应与真正的 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 是此进程的工作集的当前大小（以字节为单位）。 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.
如果您的 pods 是 limiting the resource usage，那么您应该监控两者，因为如果它们达到特定的资源限制，它们将导致 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_bytesas this is what the OOM killer is watching for.
编辑：
添加一些额外的来源作为补充：