linux限制内存空闲余量,Linux 关于内存最疑惑的几个问题

Linux 关于内存最疑惑的几个问题

Linux 关于内存最疑惑的几个问题

实际上包括四个子问题，即：

怎么理解 LRU 内存回收？

回收后的内存又到哪里去了？

OOM 是按照虚拟内存还是实际内存来打分？

怎么估计应用程序的最小内存？

一旦发现内存紧张，系统会通过三种方式回收内存。我们来复习一下，这三种方式分别是 ：

基于 LRU(Least Recently Used)算法，回收缓存

基于 Swap 机制，回收不常访问的匿名页

基于 OOM(Out of Memory)机制，杀掉占用大量内存的进程

前两种方式，缓存回收和 Swap 回收，实际上都是基于 LRU 算法，也就是优先回收不常访问的内存。LRU 回收算法，实际上维护着 active 和 inactive 两个双向链表，其中：

active 记录活跃的内存页

inactive 记录非活跃的内存页

越接近链表尾部，就表示内存页越不常访问。这样，在回收内存时，系统就可以根据活跃程度，优先回收不活跃的内存。

活跃和非活跃的内存页，按照类型的不同，又分别分为文件页和匿名页，对应着缓存回收和 Swap 回收。

当然，你可以从 /proc/meminfo 中，查询它们的大小，比如：

# grep表示只保留包含active的指标(忽略大小写)

# sort表示按照字母顺序排序

$ cat /proc/meminfo | grep -i active | sort

Active(anon): 167976 kB

Active(file): 971488 kB

Active: 1139464 kB

Inactive(anon): 720 kB

Inactive(file): 2109536 kB

Inactive: 2110256 kB

当系统发现内存不足以分配新的内存请求时，就会尝试直接内存回收。这种情况下，如果回收完文件页和匿名页后，内存够用了，当然皆大欢喜，把回收回来的内存分配给进程就可以了。但如果内存还是不足，OOM 就要登场了。

OOM 发生时，你可以在 dmesg 中看到 Out of memory 的信息，从而知道是哪些进程被 OOM 杀死了。比如，你可以执行下面的命令，查询 OOM 日志：

$ dmesg | grep -i "Out of memory"

Out of memory: Kill process 9329 (java) score 321 or sacrifice child

当然了，如果你不希望应用程序被 OOM 杀死，可以调整进程的 oom_score_adj，减小 OOM 分值，进而降低被杀死的概率。或者，你还可以开启内存的 overcommit，允许进程申请超过物理内存的虚拟内存(这儿实际上假设的是，进程不会用光申请到的虚拟内存)。

这三种方式，我们就复习完了。接下来，我们回到开始的四个问题，相信你自己已经有了答案。

LRU 算法的原理刚才已经提到了，这里不再重复。

内存回收后，会被重新放到未使用内存中。这样，新的进程就可以请求、使用它们。

OOM 触发的时机基于虚拟内存。换句话说，进程在申请内存时，如果申请的虚拟内存加上服务器实际已用的内存之和，比总的物理内存还大，就会触发 OOM。

要确定一个进程或者容器的最小内存，最简单的方法就是让它运行起来，再通过 ps 或者 smap ，查看它的内存使用情况。不过要注意，进程刚启动时，可能还没开始处理实际业务，一旦开始处理实际业务，就会占用更多内存。所以，要记得给内存留一定的余量。

Linux 关于内存最疑惑的几个问题相关教程