问题

cadvisor提供了多个容器内存相关的指标，其中最重要的是以下几个：

（From https://help.aliyun.com/document_detail/413870.html）

Pod命令如何计算内存使用量
执行kubectl top pod命令得到的结果，并不是容器服务中container_memory_usage_bytes指标的内存使用量，而是指标container_memory_working_set_bytes的内存使用量，计算方式如下：

• container_memory_usage_bytes = container_memory_rss + container_memory_cache + kernel memory

• container_memory_working_set_bytes = container_memory_usage_bytes - total_inactive_file（未激活的匿名缓存页）

• container_memory_working_set_bytes是容器真实使用的内存量，也是资源限制limit时的重启判断依据

由此可见，k8s注重container_memory_working_set_bytes（下面简称wss）。不少网上的容器告警规则范例也使用了wss。那我们到底应该用rss还是wss作为容器告警的指标呢？

上周团队内对此产生了一些疑问，这里做了一些深入的分析和实验。

解读

1. 关于active_file和inactive_file

根据https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt

active_file和inactive_file的定义为：

inactive_file   - # of bytes of file-backed memory on inactive LRU list.
active_file - # of bytes of file-backed memory on active LRU list.

Linux系统会把进程占用后多余的内存用作page cache，当访问文件后就加载到内存中，加速后面再次访问文件的速度。当系统需要更多常驻内存的时候，又会从page cache腾出空间。这种用途的内存叫做file-backed memory（相对应与文件无关的叫anonymous memory）。page cache分为inactive_file和active_file。第一次读写文件后的cache，属于inactive_file，多次访问这个文件之后，属于active_file。inactive_file的cache是会可以被操作系统直接回收使用的，active_file不会直接回收，而是先变成inactive_file。

可以用下面的实验进行验证。

实验一：

进入一个kun容器，此容器的内存limit是375MB（不是MiB）。

内核版本是5.10

root@container-0:/# uname -a
Linux container-0 5.10.134-12.2.al8.x86_64 #1 SMP Thu Oct 27 10:07:15 CST 2022 x86_64 x86_64 x86_64 GNU/Linux

cat /sys/fs/cgroup/memory/memory.limit_in_bytes          
375390208

1. 查看/sys/fs/cgroup/memory/memory.stat文件，完整内容如下：

root@container-0:/# cat /sys/fs/cgroup/memory/memory.stat             cache 3244032
rss 35553280
rss_huge 0
shmem 0
mapped_file 675840
dirty 675840
writeback 0
swap 0
pgpgin 390783690
pgpgout 390780736
pgfault 923765304
pgmajfault 0
inactive_anon 35590144
active_anon 0
inactive_file 540672
active_file 2838528
unevictable 0
hierarchical_memory_limit 375390208
hierarchical_memsw_limit 9223372036854771712
total_cache 3244032
total_rss 35553280
total_rss_huge 0
total_shmem 0
total_mapped_file 675840
total_dirty 675840
total_writeback 0
total_swap 0
total_pgpgin 390783690
total_pgpgout 390780736
total_pgfault 923765304
total_pgmajfault 0
total_inactive_anon 35590144
total_active_anon 0
total_inactive_file 540672
total_active_file 2838528
total_unevictable 0

我们关注的是：

total_cache 3244032
total_rss 35553280
total_inactive_file 540672
total_active_file 2838528

2. 写入1个100MB的文件

root@container-0:/# dd if=/dev/zero of=test_100m bs=1M count=100 
100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0.708941 s, 148 MB/s

再次查看/sys/fs/cgroup/memory/memory.stat：

total_cache 108269568
total_rss 35553280
total_inactive_file 105431040
total_active_file 2838528

cache和inactive_file增加了100MB，而rss和active_file没有变化

3. 重复读这个文件两次

root@container-0:/# cat test_100m > /dev/null

再次查看/sys/fs/cgroup/memory/memory.stat：

total_cache 108269568
total_rss 34607104
total_inactive_file 540672
total_active_file 107864064

cache和rss没有变化，inactive_file减少100MB，active_file增加了100MB。

可见多次访问此文件后，内存cache从inactive变成了active。

对应，容器的指标曲线：

image.png

4. 重复访问多个100MB文件

root@container-0:/# cp test_100m{,.1}
root@container-0:/# cp test_100m{,.2}
root@container-0:/# cp test_100m{,.3}
root@container-0:/# cat test_100m.1 > /dev/null
root@container-0:/# cat test_100m.1 > /dev/null
root@container-0:/# time cat test_100m.2 > /dev/null
real    0m0.965s
user    0m0.000s
sys     0m0.092s
root@container-0:/# 
root@container-0:/# time cat test_100m.2 > /dev/null
real    0m0.091s
user    0m0.000s
sys     0m0.019s
root@container-0:/# time cat test_100m.3 > /dev/null
real    0m0.922s
user    0m0.001s
sys     0m0.095s
root@container-0:/# time cat test_100m.3 > /dev/null
real    0m0.110s
user    0m0.000s
sys     0m0.021s

第二次读文件的时候，耗时变短，说明已经使用了cache。

查看/sys/fs/cgroup/memory/memory.stat：

total_cache 342380544
total_rss 33660928
total_inactive_file 123699200
total_active_file 217837568

cache已经使用了300MB+，但inactive并不会全部转成active（跟文件大小有关，如果是10MB的文件，active会用的更多）。

查看usage：

root@container-0:/# cat /sys/fs/cgroup/memory/memory.usage_in_bytes
374579200

image.png

从指标数据看，container_memory_working_set_bytes是251MB，跟usage - total_inactive_file = 374-123 = 251MB能对应上。

5. 尝试清理page cache

root@container-0:/# echo 1 > /proc/sys/vm/drop_caches
bash: /proc/sys/vm/drop_caches: Read-only file system

在Linux主机上，我们可以执行上面的命令来清理cache，但在容器里执行报错。说明只能清理整个操作系统的cache，无法只清理cgroup产生的cache。

6. 增加RSS内存使用

通过一个简单脚本，逐渐增加容器中的RSS内存使用。

image.png

从18:12开始，可以看到随着rss内存增加，wss也逐渐增加，cache逐渐减少。

观察/sys/fs/cgroup/memory/memory.stat：

最初：
total_rss 102707200
total_inactive_file 135884800
total_active_file 135843840
=>
total_rss 205164544
total_inactive_file 85196800
total_active_file 85307392
=>
total_rss 300863488
total_inactive_file 37302272
total_active_file 37400576
=>
total_rss 374124544
total_inactive_file 581632
total_active_file 749568

可以看到：

1. rss + active_file + inactive_file不会超过memory limit

2. 并不是先把inactive_file先回收完才回收active_file部分的，而是随着inactive_file减少，部分active_file会变成inactive_file，两者维持一定的比例。从上面曲线中wss的上升速度比rss上升慢也推导出active_file部分是在减少的。

直到最后cache已经回收完了，内存不够分配，容器发生了OOMKilled。

2. 理解container_memory_working_set_bytes

working set是Linux中的概念，但没有一个严格的定义，比如解释1，解释2，解释3等。

在k8s文档中，对working set的描述是：

image.png

结合cadvisor中container_memory_working_set_bytes指标的计算方法，wss可以约等于rss+active_file。

上面highlight的文字也解释了为什么k8s选择wss作为监控指标，即active_file部分的cache不是总能被回收。这里没有明确说，但在这份kernel文档的10.1部分有提到active_list什么时候能迁移到inactive_list，就是没有再被引用的情况下。一种场景是如果写大量数据到文件，已经写入内存cache但还没来得及回写完到磁盘，这时的active_file就是被引用的。

内核中dirty_writeback_centisecs的值默认值是5秒，一般不会导致大量写数据积压。但由于无法衡量active_file中有多少可以变为inactive_file从而被回收，因此k8s保险起见，选择了active_file都要被计算在内存使用量以内。

由此可见：

1. container_memory_usage_bytes > container_memory_working_set_bytes > container_memory_rss

2. 如果要申请的内存量 > limit - rss，内存分配必定失败 如果要申请的内存量 > limit - wss，又有可能成功，也有可能失败，取决于active_file能回收的部分够不够多

接下来，如果容器中的应用申请内存失败，会发生什么事情？

3. 延伸：容器发生OOM，到底指的是什么？

有很详细的文章介绍：

• https://izsk.me/2023/02/15/Kubernetes-Out-Of-Memory-2/

• 英文原文

结合文章内容及我的理解，要点是：

1. 在k8s上，同时有Pod驱逐和OOM Killer两套机制在工作

2. Pod驱逐在节点内存不足时按配置的策略驱逐个别容器到其他节点，是保护不会因为节点自身OOM整体挂掉。 驱逐机制见文档。 这时容器退出的原因是Evicted，不算是容器发生OOM

3. OOM Killer则是Linux的机制，k8s不直接控制，但：

   1. 通过oom_score_adj参数调整OOM的行为

   2. 监控容器是否发生了OOM Kill事件导致容器退出，如果有会标记退出的reason为OOMKilled

4. OOM Killer运行在两个层面：

   1. 节点OS的OOM Killer，当节点内存不足时杀进程，但不管是不是容器的进程，也是起到了保护节点的作用

   2. 容器内部的OOM Killer，当容器内存分配不足时，杀容器内部的进程。如果是杀主进程就会导致容器退出。 这时内存分配不足时，有可能rss很高，也rss不高但wss很高，即cache中有部分未及时回写磁盘导致内存无法回收。

实验二

1. 让容器发生OOMKilled退出

通过简单脚本，每运行一次消耗1MB内存，直到RSS内存打满。即实验一中的第六步。

由于RSS打满时，主进程是内存使用量最高的，因此被kill掉，容器退出。

image.png

2. 容器内部发生OOM但不退出

通过简单脚本，每运行一次消耗100MB内存，直到RSS内存打满。

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                                    
  54209 root      20   0  111940 110676   1376 S   0.0   0.1   0:00.10 tail                                                                                                       
  54226 root      20   0  111940 110676   1376 S   0.0   0.1   0:00.10 tail                                                                                                       
  54350 root      20   0  111128 109884   1384 S   0.0   0.1   0:00.09 tail

此时再执行一次脚本，发现有旧进程54226退出，多了一个新进程54475。

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                                    
  54209 root      20   0  111940 110676   1376 S   0.0   0.1   0:00.10 tail                                                                                                       
  54475 root      20   0  110992 110008   1520 S   0.0   0.1   0:00.08 tail                                                                                                       
  54350 root      20   0  111128 109884   1384 S   0.0   0.1   0:00.09 tail

dmesg中可以看到oom信息

root@container:/# dmesg | grep oom
[8306983.891401] tail invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj=999

从图上看，WSS已经打满，但主进程没有受影响，容器还在正常运行。

image.png

3. 想尝试节点内存不足导致的OOM Kill和Pod驱逐，没有环境

回顾问题

回到最初的问题，容器内存使用率告警，应该用rss还是wss指标。那要看我们是要对什么问题做预警。

预警容器OOM

从解读3可以看出，容器发生OOM有三种情况：

1. cache都已经被回收： 容器的rss使用率和wss使用率都很高，没法再分配出内存。 如果主进程是占用内存最多的进程，主进程被容器内OOM Killer杀掉

2. cache无法回收： 容器的rss使用率不高，瞬间大量写数据无法及时回写磁盘导致wss使用率很高，再申请内存时无法分配。 如果主进程是占用内存最多的进程，主进程被容器内OOM Killer杀掉

3. 节点内存不足，某容器主进程的rss内存使用量最高，跟使用率无关。 此时容器主进程被节点OOM Killer杀掉

对于第一种情况，预警容器OOM可以使用wss或rss使用率的规则。

第二种情况，由于通常是突发写数据造成，无论用wss或rss使用率都无法及时告警。

对于第三种情况，应该用节点内存使用率的告警，通知给集群维护者。对于容器rss使用率和使用量，告警给容器使用方没有意义（使用量无法定阈值，使用率很高但使用量低不会在节点层面被kill）。

预警容器被驱逐

从解读3可以看出，容器被被驱逐的必要条件，是节点内存不足，按照策略驱逐个别容器，跟容器wss使用率和rss使用率无关。

因此预警容器被驱逐，应该用节点内存使用率的告警，通知给集群维护者。对于容器wss使用率和使用量，告警给容器使用方没有意义（使用量无法定阈值，使用率很高不代表会优先被驱逐）。

这里还需要注意的是，驱逐机制是按节点的wss来判断是否达到了驱逐条件，见文档。

结论

从上面可以看出，使用wss指标做告警，并没有比rss更优。

然后，wss指标存在几个问题：

1. wss很高，可能只是active_file内存占用多，需要的时候是可以被回收的。使用wss容易出现用户无需处理的误告

2. rss指标更符合大家的使用习惯，使用wss更难以对业务方解释。在传统的Linux主机监控，我们一般用MemTotal-MemAvailable内存大小代表主机的内存使用水位，并对此做告警。其中MemAvailable包含page cache，见文档，这也与wss的定义不同。

综上，没有必要使用container_memory_working_set_bytes作为容器内存使用率的告警，使用container_memory_rss即可。

无法解决的告警问题：

1. 突发的大量内存申请，由于告警周期是是1分钟，可能在OOM前不会触发告警。

2. 如果容器内存使用率的定义为rss/limit，在节点允许超卖的情况下（limit > request），仍有可能出现容器内存使用率不高，但节点由于超卖过多、内存压力大导致OOM或者被驱逐的问题。这时可能不会触发告警。

参考资料

实际Linux的内存管理很复杂，概念也很多，一些资料：

Cgroup - Linux内存资源管理

Chapter 10 Page Frame Reclamation（Page Cache回收机制）