如何诊断高“Shmem”？（是：为什么 `echo 3 > drop_caches` 不能将缓存清零？）

Question 1

我是上述问题的作者，尽管到目前为止还没有完整的答案，但这是迄今为止最著名的解释：

对于现代 Linux 内核，Cached的值/proc/meminfo不再描述磁盘缓存的数量。然而，内核开发人员认为此时更改此设置已经为时已晚。
在实践中，要实际测量正在使用的磁盘缓存量，您应该进行计算Cached - Shmem来估计它。如果您从原始问题中获取数字，您将得到15151936−14707664(kiB)（来自/proc/meminfo）或444272(kiB) 的输出，因此看来系统实际上拥有大约 433 MiB 的磁盘缓存。在这种情况下，很明显，删除所有磁盘缓存不会释放大量内存（即使删除所有磁盘缓存，该Cached字段也只会减少 3%。

因此，最好的猜测是某些用户模式软件使用了大量共享内存（通常tmpfs或共享内存映射），这导致Cached显示高值，尽管系统实际上只有很少的磁盘缓存，这表明它接近进入内存不足的情况。我认为Committed_AS这远远MemTotal支持了这一理论。

这是上述链接线程的结论的（缩短的）副本，linux-mm以防上述链接将来不起作用：

主题：回复：为什么 Shmem 包含在 Cached in /proc/meminfo 中？
来自：Vlastimil Babka @ 2021-08-30 16:05 UTC

21 年 8 月 30 日凌晨 12:44，Mikko Rantalainen 写道：

从 fs/proc/meminfo.c 函数 meminfo_proc_show() 来看，这并不是很明显，但是 Cached: 字段的输出似乎也总是包含所有 Shmem: 字段

然而，如果我们现在改变它，我们可能会造成更大的混乱。人们第一次在新内核上查看输出（IIRC 也是“free”命令使用它）时就不会再被误导了。但是使用新旧内核的人们现在必须考虑到它在某些时候发生了变化......不好。

来自：哈立德·阿齐兹 @ 2021-08-30 19:38 UTC

2021 年 8 月 30 日星期一 20:26 +0300，Mikko Rantalainen 写道：

当然，一种可能的解决方案是保持“Cached”不变，并引入具有真实缓存语义的“Cache”（即，它包括（Cached - Shmem）和内存支持的 RAM 的总和）。这样系统管理员至少会看到两个具有唯一值的不同字段并查找文档。

我建议添加新字段。可能有大量工具/脚本已经解释了 /proc/meminfo 中的数据，并可能根据该数据采取行动。如果我们改变现有数据的含义，这些工具就会崩溃。新字段的缺点是会进一步扩大输出，但它也不会破坏现有的工具。

Answer

我是上述问题的作者，尽管到目前为止还没有完整的答案，但这是迄今为止最著名的解释：

对于现代 Linux 内核，Cached的值/proc/meminfo不再描述磁盘缓存的数量。然而，内核开发人员认为此时更改此设置已经为时已晚。
在实践中，要实际测量正在使用的磁盘缓存量，您应该进行计算Cached - Shmem来估计它。如果您从原始问题中获取数字，您将得到15151936−14707664(kiB)（来自/proc/meminfo）或444272(kiB) 的输出，因此看来系统实际上拥有大约 433 MiB 的磁盘缓存。在这种情况下，很明显，删除所有磁盘缓存不会释放大量内存（即使删除所有磁盘缓存，该Cached字段也只会减少 3%。

因此，最好的猜测是某些用户模式软件使用了大量共享内存（通常tmpfs或共享内存映射），这导致Cached显示高值，尽管系统实际上只有很少的磁盘缓存，这表明它接近进入内存不足的情况。我认为Committed_AS这远远MemTotal支持了这一理论。

这是上述链接线程的结论的（缩短的）副本，linux-mm以防上述链接将来不起作用：

主题：回复：为什么 Shmem 包含在 Cached in /proc/meminfo 中？
来自：Vlastimil Babka @ 2021-08-30 16:05 UTC

21 年 8 月 30 日凌晨 12:44，Mikko Rantalainen 写道：

从 fs/proc/meminfo.c 函数 meminfo_proc_show() 来看，这并不是很明显，但是 Cached: 字段的输出似乎也总是包含所有 Shmem: 字段

然而，如果我们现在改变它，我们可能会造成更大的混乱。人们第一次在新内核上查看输出（IIRC 也是“free”命令使用它）时就不会再被误导了。但是使用新旧内核的人们现在必须考虑到它在某些时候发生了变化......不好。

来自：哈立德·阿齐兹 @ 2021-08-30 19:38 UTC

2021 年 8 月 30 日星期一 20:26 +0300，Mikko Rantalainen 写道：

当然，一种可能的解决方案是保持“Cached”不变，并引入具有真实缓存语义的“Cache”（即，它包括（Cached - Shmem）和内存支持的 RAM 的总和）。这样系统管理员至少会看到两个具有唯一值的不同字段并查找文档。

我建议添加新字段。可能有大量工具/脚本已经解释了 /proc/meminfo 中的数据，并可能根据该数据采取行动。如果我们改变现有数据的含义，这些工具就会崩溃。新字段的缺点是会进一步扩大输出，但它也不会破坏现有的工具。

Question 2

我现在正在写帮助诊断内存问题的工具，基于a中的信息来自 RedHat 的文档，其中包含一些公式。

关于磁盘缓存/tmpfs，我的理解是：

缓存 = 磁盘缓存 - 交换缓存 - tmpfs 内存使用情况

tmpfs可以驻留在swap中，因此我们必须首先计算tmpfs的实际内存使用情况。

简单的解决方案：

shmem = 共享内存段 + tmpfs ram

不过，共享内存段也可以在swap中，并且shmem似乎不包括大页共享内存段（在内核5.4和5.15上测试）。

更精确的解决方案

shmem =“4k 页 sysvipc shm rss”+ tmpfs ram 使用情况

“4k sysvipc shm rss”是标准页面大小（4k）的共享内存段使用的内存总和，因此没有大页面。

您可以在下获取内存段的 RSS 使用情况/proc/sysvipc/shm。

shm 使用 4k 或 2M 页面的事实似乎并未在 /proc 下公开，但可以通过附加到共享内存段并扫描物理页面来获取该信息 ( /proc/kpageflags)。我用它来将共享内存页的数量添加到输出中：

sudo ./memstats groups
[...]
Scanning shm...
Shared memory segments (MiB):
         key           id       Size        RSS         4k/2M        SWAP   USED%        SID
============================================================================================
           0            3          9          9       2442/0            0  100.02           
           0            2          9         10          0/5            0  104.86           
[...]

Answer