什么是 vm.min_free_kbytes

vm.min_free_kbytes是用于 linux 内核的 vm.min_free_kbytes sysctl 可调参数；

引言

　　它应该设置为什么值？我们将在本文中研究此参数以及它如何影响正在运行的 linux 系统。

我们将测试它对 OS 页面缓存和 malloc 的影响，以及设置此参数时 system free 命令显示的内容。我们将对这个可调参数的理想值进行一些有根据的猜测，我们将展示如何永久设置 vm.min_free_kbytes 以在重新启动后继续存在。

vm.min_free_kbytes 如何工作

　　系统可能需要内存分配以确保系统本身的正常运行。如果内核允许分配所有内存，则在需要内存进行常规操作以保持操作系统平稳运行时，它可能会遇到困难。这就是内核提供可调 vm.min_free_kbytes 的原因。该可调参数将强制内核的内存管理器保留至少 X 量的空闲内存。这是来自linux内核文档的官方定义：“这用于强制 Linux VM 保持最小数量的可用千字节。VM 使用这个数字来计算系统中每个 lowmem 区域的 watermark[WMARK_MIN] 值。每个 lowmem 区域都会根据其大小按比例获得一些保留的空闲页面。满足 PF_MEMALLOC 分配需要一些最小的内存量；如果您将其设置为低于 1024KB，您的系统将被巧妙地破坏，并且在高负载下容易死锁。设置得太高会立即 OOM 你的机器。“

验证 vm.min_free_kbytes 工作

　　为了测试 min_free_kbytes 的设置是否按设计工作，我创建了一个只有 3.75 GB RAM 的 linux 虚拟实例。使用下面的免费命令来分析系统：

  #free -m

　　查看上面的可用内存实用程序，使用 -m 标志以 MB 为单位打印值。总内存为 3.5 到 3.75 GB 内存。使用了 121 MB 内存，3.3 GB 内存可用，251 MB 用于缓冲区高速缓存。并且有 3.3 GB 的内存可用。

　　现在我们要改变 vm.min_free_kbytes 的值，看看对系统内存有什么影响。我们会将新值回显到 proc 虚拟文件系统以更改内核参数值，如下所示：

# echo 1500000 > /proc/sys/vm/min_free_kbytes
# sysctl vm.min_free_kbytes

可以看到参数改成大约1.5GB，已经生效了。现在让我们再次使用free命令来查看系统识别的任何更改。

  #free -m

　　该命令不会更改可用内存和缓冲区高速缓存，但显示为可用的内存量已从 3327 MB 减少到 1222 MB。这是参数变化的近似减少到 1.5 GB 最小可用内存。

　　现在让我们创建一个 2GB 的数据文件，然后看看将该文件读入缓冲区缓存对值的影响。以下是如何在下面的 2 行 bash 脚本中创建 2GB 数据文件。该脚本将使用 dd 命令生成一个 35MB 的随机文件，然后将其复制 70 次到一个新的data_file输出中：

# dd if=/dev/random of=/root/d1.txt count=1000000
# for i in `seq 1 70`; do echo $i; cat /root/d1.txt >> /root/data_file; done

　　让我们通过读取文件并将其重定向到 /dev/null 来读取文件并忽略内容，如下所示：

# cat data_file > / dev / null

　　通过这组操作，我们的系统内存发生了什么，现在让我们检查一下：

#free -m

　　分析上面的结果。由于我们的 min_free_kbytes 设置，我们仍然有 1.8 GB 的空闲内存，因此内核保护了一大块内存作为保留。缓冲区缓存使用了 1691 MB，小于我们数据文件的总大小 2.3 GB。显然，由于缺少用于缓冲区高速缓存的可用内存，整个data_file无法存储在高速缓存中。我们可以验证整个文件没有存储在缓存中，而是对重复尝试读取文件进行计时。如果它被缓存，读取文件需要几分之一秒。

cat data_file > /dev/null

文件读取花费了将近 20 秒，这意味着它几乎肯定不会全部缓存。

 

　　作为最后的验证，让我们减少 vm.min_free_kbytes 以允许页面缓存有更多的操作空间，我们可以期望看到缓存工作并且文件读取变得更快。

# echo 67584 > /proc/sys/vm/min_free_kbytes #time
cat data_file > /dev/null
# time cat data_file > /dev/null

　　由于可用于缓存的额外内存，文件读取时间从之前的 20 秒下降到 0.364 秒，并且全部在缓存中。

　　我很想再做一个实验。面对这个非常高的 vm.min_free_kbytes 设置，从 C 程序分配内存的 malloc 调用会发生什么情况。它会失败malloc吗？系统会死吗？首先将 vm.min_free_kbytes 设置重置为非常高的值以继续我们的实验：

# echo 1500000 > / proc / sys / vm / min_free_kbytes

　　让我们再看看我们的空闲内存：

　　理论上，我们有 1.9 GB 可用空间和 515 MB 可用空间。让我们使用一个名为stress-ng 的压力测试程序来使用一些内存，看看我们失败的地方。我们将使用 vm 测试器并尝试分配 1 GB 的内存。由于我们在 3.75 GB 系统上只保留了 1.5 GB，我想这应该可行。

　　让我们用更多的进程再试一次，我们可以尝试 1、2、3、4 个进程，但在某些时候它应该会失败。在我的测试中，它通过了 1 和 2 进程，但没有通过 第3个 进程。

　　让我们将 vm.min_free_kbytes 重置为一个较低的数字，看看这是否有助于我们在 3.75GB 系统上运行 3 个内存压力源，每个 1GB。

# echo 67584 > /proc/sys/vm/min_free_kbytes
#stress-ng --vm3 --vm-bytes 1G --timeout 60s

　　这次它运行成功，没有错误，我试了两次没有问题。所以我可以得出结论，当 vm.min_free_kbytes 值设置为较低值时，有更多内存可用于 malloc 的行为差异。

vm.min_free_kbytes 的默认设置

　　我系统上设置的默认值是 67584，大约是系统 RAM 的 1.8% 或 64 MB。出于安全原因，在一个严重颠簸的系统上，我倾向于将其增加一点，可能会增加到 128MB 以允许更多保留的可用内存，但是对于平均使用情况，默认值似乎足够明智。官方文档警告不要将值设置得太高。将其设置为系统 RAM 的 5% 或 10% 可能不是该设置的预期用途，而且太高了。

设置 vm.min_free_kbytes 以在重新启动后继续存在

　　为了确保设置可以在重新启动后继续存在并且不会在重新启动时恢复为默认值，请务必通过将所需的新值放入 /etc/sysctl.conf 文件中来使 sysctl 设置保持不变。

结论：

　　我们已经看到 vm.min_free_kbytes linux 内核可调参数可以修改，并且可以在系统上保留内存，以确保系统更加稳定，尤其是在大量使用和大量内存分配期间。默认设置可能有点太低，尤其是在高内存系统上，应考虑谨慎增加。我们已经看到，此可调参数保留的内存可防止操作系统缓存使用所有内存，也可防止某些 malloc 操作使用所有内存。

 

标签：kbytes,min,vm,free,GB,内存
来源： https://www.cnblogs.com/yinguojin/p/16418072.html