记一次查 Linux 内存：free、available 和 buff/cache

在云服务器上敲 free -h，十个人里起码有八个第一次见都会被吓一跳。明明没跑什么大业务，4G 的机器，used 显示吃了两三 G，free 剩下可怜的两三百兆。有的朋友甚至去配定时任务跑 echo 3 > /proc/sys/vm/drop_caches，以为这样是在优化性能，其实完全没必要。

标准的 free -h 输出通常长这样：

              total        used        free      shared  buff/cache   available
Mem:           3.8G        1.1G        280M         16M        2.4G        2.5G
Swap:          2.0G          0B        2.0G

Linux 的内存设计思路很直接，空闲内存空放着也是浪费，不如全拿来干活。

跟内存读写比起来，磁盘 I/O 慢得多。内核有个极其贪心的策略，只要物理内存还没被进程撑满，所有读过的文件、写过的日志，全都会在内存里留一份备份，也就是 buff/cache。后续无论哪个进程再访问同一份数据，内核直接从内存里秒回，不需要再去啃慢速磁盘。

这时候看终端，free 这一项当然只有一点点。但关键在后面那列 available。

available 才是真正的可用内存。它包含了当前干干净净的 free，还算上了绝大部分可以随时被踢出去的缓存页。

为什么缓存能被随时踢出去？因为平时读取文件生成的 Page Cache，在内存里叫干净页（Clean Page）。它们在磁盘上本来就有原件，内核丢弃它们不需要做任何写盘操作，耗时微秒级，业务根本感知不到。只有被程序修改过还没来得及同步到磁盘的脏页（Dirty Page），才需要等待刷盘。敲一行 cat /proc/meminfo | grep -i dirty 看看就知道，日常运行中 Dirty 通常只有几百 KB 到几兆，对内存回收毫无阻碍。

经常有人喜欢手动执行 echo 3 > /proc/sys/vm/drop_caches 清理缓存。敲完看一眼，free 确实暴涨回好几个 G，看着舒服了，但整台机器反而会变卡。接下来所有系统命令、程序读取配置文件，全都要重新从磁盘里冷读一遍，凭空制造大量磁盘 I/O。

真正该盯紧的是下面这两种危险状态。

首先看 available 的具体数字。要是可用量跌到了总内存的 10% 以下，说明连缓存都已经被压缩到了极限，系统确实没缓冲余量了。

其次看 Swap 的活动状态。敲个 vmstat 1 盯两眼，重点看 si（swap in）和 so（swap out）这两列。如果持续跳动较大的数字，说明物理内存连基本的进程运行空间都保不住了，内核正在硬着头皮在磁盘和内存之间疯狂倒腾数据。这时候该扩内存扩内存，该排查泄漏排查泄漏。

只要 available 还充足，si/so 长期归零，看到 free 只有几十兆完全不用管它。让内核自己管内存，远比人去干预靠谱得多。