/proc/meminfo 中的 Committed_AS 真的是 Linux 中分配的虚拟内存的正确数字吗？它小于 used/RSS

Question 1

这些盒子没有明显的内存压力。分页也没有（SwapFree）。第二个盒子占用了约 47 GB，总共 250 GB。200 GB 足够了。

实际上，不断增加工作负载的大小，直到发生以下情况之一：

用户（应用程序）响应时间降低
页面输出率高于您可接受的水平
OOM killer 杀死了一些进程

内存计数器之间的关系不直观，在不同的工作负载之间差异很大，可能只有内核开发人员才能真正理解。不要太担心，专注于测量明显的内存压力。

不久前在 linux-mm 列表中对 Comitted_AS 的其他描述强调这是一个估计值：

Committed_AS: An estimate of how much RAM you would need to make a
              99.99% guarantee that there never is OOM (out of memory)
              for this workload. Normally the kernel will overcommit
              memory. That means, say you do a 1GB malloc, nothing
              happens, really. Only when you start USING that malloc
              memory you will get real memory on demand, and just as
              much as you use. So you sort of take a mortgage and hope
              the bank doesn't go bust. Other cases might include when
              you mmap a file that's shared only when you write to it
              and you get a private copy of that data. While it normally
              is shared between processes. The Committed_AS is a
              guesstimate of how much RAM/swap you would need
              worst-case.

Answer

这些盒子没有明显的内存压力。分页也没有（SwapFree）。第二个盒子占用了约 47 GB，总共 250 GB。200 GB 足够了。

实际上，不断增加工作负载的大小，直到发生以下情况之一：

用户（应用程序）响应时间降低
页面输出率高于您可接受的水平
OOM killer 杀死了一些进程

内存计数器之间的关系不直观，在不同的工作负载之间差异很大，可能只有内核开发人员才能真正理解。不要太担心，专注于测量明显的内存压力。

不久前在 linux-mm 列表中对 Comitted_AS 的其他描述强调这是一个估计值：

Committed_AS: An estimate of how much RAM you would need to make a
              99.99% guarantee that there never is OOM (out of memory)
              for this workload. Normally the kernel will overcommit
              memory. That means, say you do a 1GB malloc, nothing
              happens, really. Only when you start USING that malloc
              memory you will get real memory on demand, and just as
              much as you use. So you sort of take a mortgage and hope
              the bank doesn't go bust. Other cases might include when
              you mmap a file that's shared only when you write to it
              and you get a private copy of that data. While it normally
              is shared between processes. The Committed_AS is a
              guesstimate of how much RAM/swap you would need
              worst-case.

Question 2

Committed_AS以下是另一个纯粹关于低于“预期”的答案：

您说的有趣内容/proc/meminfo如下：

Active:          4854772 kB
Inactive:        5386896 kB
Active(anon):      33468 kB
Inactive(anon):   412616 kB
Active(file):    4821304 kB
Inactive(file):  4974280 kB
Mlocked:           10948 kB
AnonPages:        428460 kB
Shmem:             26336 kB
Committed_AS:    1488188 kB

（Active和Inactive只是稍后(anon)vs细节的总和，而只是带有标识符的行的总和——我只包含这些行以使其更容易理解。）(file)AnonPages(anon)

由于Active(file)文件支持不会导致任何增加，Committed_AS因此实际上唯一真正增加您的Committed_AS值的是内存使用量的AnonPages+ Shmem+ + 峰值。这是系统必须能够为当前正在运行的进程提供的内存量（RAM+交换组合），即使所有缓存和缓冲区都刷新到磁盘。MlockedCommitted_AS

如果某个进程确实（通常在后台malloc()实现）内核将增加sbrk()brk()Committed_AS），内核将会增加，但不会显示在其他数字中，因为内核实际上并没有保留任何实际 RAM，直到进程实际使用内存为止。（从技术上讲，内核已指定要用于进程的虚拟内存地址空间范围，但 CPU 的虚拟内存映射指向零填充页面，并带有一个标志，如果进程尝试写入任何内容，则必须动态分配实际内存 - 这允许进程从虚拟地址空间读取零而不会导致 CPU 故障，但将数据写入虚拟分配的内存区域是实际分配内存的操作。）这是非常程序分配的（虚拟）内存比实际使用的内存多，这是很常见的情况，因此这是个很好的功能，但显然会使内存统计信息更难理解。似乎您的系统主要运行的进程不会获取大量未实际使用的内存，因为Committed_AS与其他值相比，您的内存相当低。

例如我现在的系统目前运行情况如下：

MemTotal:       32570748 kB
Active:         12571828 kB
AnonPages:       7689584 kB
Mlocked:           19788 kB
Shmem:           4481940 kB
Committed_AS:   44949856 kB

注意巨大的Committed_AS尽管匿名页面总数、锁定内存加上总计约为 12 GB，但我的系统中仍然有大约 45 GB的内存Shmem。由于我在此系统上运行桌面环境，因此我假设我有许多进程已经执行fork()。由于我在此系统上运行桌面环境，因此我假设在获取/使用大量 RAM 后执行了许多进程。在这种情况下，分叉进程可以理论上修改所有内存而不进行任何显式内存分配，并且所有这些分叉内存都会向上计算值Committed_AS。因此，Committed_AS可能根本无法反映您的实际系统内存使用情况。

总结： Committed_AS是估计分配的虚拟内存没有任何文件系统备份或必须由实际存储（RAM+交换）支持的最大内存量理论上保持当前正在运行的进程继续运行，如果没有什么在整个系统中分配更多内存。

但是，如果系统正在与外界通信，即使是传入的 IP 数据包也可能会导致使用更多的内存，因此您无法保证未来基于此数字的系统行为。还请注意，堆栈内存始终是动态分配的，因此即使您的任何进程都没有fork()进行显式内存分配，Committed_AS当进程使用更多堆栈空间时，您的内存使用量 ( ) 仍可能会增加。

以我的经验来看，Committed_AS只有与之前的运行进行比较才真正有意义类似的工作量。但是，如果Committed_AS小于您的，MemTotal那么您可以肯定，与可用硬件相比，系统的内存压力非常小。

Answer

Committed_AS以下是另一个纯粹关于低于“预期”的答案：

您说的有趣内容/proc/meminfo如下：

Active:          4854772 kB
Inactive:        5386896 kB
Active(anon):      33468 kB
Inactive(anon):   412616 kB
Active(file):    4821304 kB
Inactive(file):  4974280 kB
Mlocked:           10948 kB
AnonPages:        428460 kB
Shmem:             26336 kB
Committed_AS:    1488188 kB

（Active和Inactive只是稍后(anon)vs细节的总和，而只是带有标识符的行的总和——我只包含这些行以使其更容易理解。）(file)AnonPages(anon)

由于Active(file)文件支持不会导致任何增加，Committed_AS因此实际上唯一真正增加您的Committed_AS值的是内存使用量的AnonPages+ Shmem+ + 峰值。这是系统必须能够为当前正在运行的进程提供的内存量（RAM+交换组合），即使所有缓存和缓冲区都刷新到磁盘。MlockedCommitted_AS

如果某个进程确实（通常在后台malloc()实现）内核将增加sbrk()brk()Committed_AS），内核将会增加，但不会显示在其他数字中，因为内核实际上并没有保留任何实际 RAM，直到进程实际使用内存为止。（从技术上讲，内核已指定要用于进程的虚拟内存地址空间范围，但 CPU 的虚拟内存映射指向零填充页面，并带有一个标志，如果进程尝试写入任何内容，则必须动态分配实际内存 - 这允许进程从虚拟地址空间读取零而不会导致 CPU 故障，但将数据写入虚拟分配的内存区域是实际分配内存的操作。）这是非常程序分配的（虚拟）内存比实际使用的内存多，这是很常见的情况，因此这是个很好的功能，但显然会使内存统计信息更难理解。似乎您的系统主要运行的进程不会获取大量未实际使用的内存，因为Committed_AS与其他值相比，您的内存相当低。

例如我现在的系统目前运行情况如下：

MemTotal:       32570748 kB
Active:         12571828 kB
AnonPages:       7689584 kB
Mlocked:           19788 kB
Shmem:           4481940 kB
Committed_AS:   44949856 kB

注意巨大的Committed_AS尽管匿名页面总数、锁定内存加上总计约为 12 GB，但我的系统中仍然有大约 45 GB的内存Shmem。由于我在此系统上运行桌面环境，因此我假设我有许多进程已经执行fork()。由于我在此系统上运行桌面环境，因此我假设在获取/使用大量 RAM 后执行了许多进程。在这种情况下，分叉进程可以理论上修改所有内存而不进行任何显式内存分配，并且所有这些分叉内存都会向上计算值Committed_AS。因此，Committed_AS可能根本无法反映您的实际系统内存使用情况。

总结： Committed_AS是估计分配的虚拟内存没有任何文件系统备份或必须由实际存储（RAM+交换）支持的最大内存量理论上保持当前正在运行的进程继续运行，如果没有什么在整个系统中分配更多内存。

但是，如果系统正在与外界通信，即使是传入的 IP 数据包也可能会导致使用更多的内存，因此您无法保证未来基于此数字的系统行为。还请注意，堆栈内存始终是动态分配的，因此即使您的任何进程都没有fork()进行显式内存分配，Committed_AS当进程使用更多堆栈空间时，您的内存使用量 ( ) 仍可能会增加。

以我的经验来看，Committed_AS只有与之前的运行进行比较才真正有意义类似的工作量。但是，如果Committed_AS小于您的，MemTotal那么您可以肯定，与可用硬件相比，系统的内存压力非常小。

Question 3

根据我的经验，Committed_AS比更准确MemAvailable。尤其是在工作量非常大的情况下，MemAvailable似乎更像是短时间内的某种平均值，而不是真实值。

话虽如此，我不记得使用过Committed_AS版本高于 4.15 的内核数据，所以我不知道历史行为是否不同。

和Committed_AS都是MemAvailable官方的内核级启发式方法，因此都不应被视为真实事实。

对于我用来运行的工作负载，当Committed_AS超过实际 RAM 量的 150% 时，我通常会开始遇到性能问题。但是，这显然在很大程度上取决于您的工作负载。如果您有大量泄漏的进程和足够的交换空间，您Committed_AS可能会继续攀升而不会出现性能问题，因为进程会泄漏 RAM，并且内核会将泄漏的 RAM 区域交换到交换空间。请注意，在这种情况下，Committed_AS最终可能会远高于总 RAM + 交换空间而不会出现任何问题。

除非您运行的是硬实时系统，否则我不会禁用内存过量使用。而且这样的系统可能也不应该使用任何交换。我个人总是将其/proc/sys/vm/overcommit_memory设置为1。

如果你可以提供足够的交换空间，通常增加交换空间/proc/sys/vm/watermark_scale_factor并/proc/sys/vm/watermark_boost_factor避免由于交换而导致的延迟是有意义的。但是，重要的是要了解Committed_AS当前已提交的内存（用户模式进程请求的内存，但通常未完全使用）以及具有 RAM+交换覆盖，可以处理所有情况没有进程分配任何新内存除非你运行一些非常奇特的系统，否则多个进程会不断分配新内存，因此你不应该对未来行为系统。如果您的工作负载非常高，那么当前的数字几乎无法反映系统未来的行为。

对于现代系统，我会关注那些可以包含内存管理中所有最高短期峰值的统计数据。我猜想一个制作精良的统计程序会通过监控内核事件/sys/fs/cgroup/memory/cgroup.event_control并在内存压力最高时收集统计数据。不过，我不知道有哪个统计应用程序真正支持这一点。任何仅在挂钟定义的采样周期内收集数据的统计应用程序都会错过大部分 RAM 使用率的短期峰值。对于数学上正确的样本平均值，挂钟采样周期是必需的，但了解峰值比获得准确的平均值更重要，因为正是这些峰值而不是平均值会破坏您的进程/性能。

Answer