free -h重点看 available 列,它才代表真正还能用多少。
约 1260 字大约 4 分钟
2026-05-14
新手看 free 输出常常吓一跳:“内存怎么快用完了?”其实那多半是缓存,随时能让出来。Linux 的内存管理和直觉不太一样——理解 available 这一列、理解缓存的角色、理解 swap 和 OOM,才能判断内存到底有没有真的紧张。
读懂 free 输出,理解 Linux 用空闲内存做缓存,看 available 而非 free 判断可用内存,弄清 swap 和 OOM 的信号。
free -h重点看 available 列,它才代表真正还能用多少。
ps aux --sort=-%mem | head按内存占用排序,揪出 RSS 最高的进程。
vmstat 1持续观察 si/so(换入换出),判断 swap 是否在频繁动。
journalctl -k | grep -i oom内核有没有因内存耗尽杀过进程,这是铁证。
free -h 的典型输出:
total used free shared buff/cache available
Mem: 7.7G 2.1G 180M 90M 5.4G 5.2G新手会盯着 free 只剩 180M 而慌张。但关键不是 free,是 available(5.2G):
buff/cache(5.4G)是 Linux 拿空闲内存做的磁盘缓存——它在“借用”内存加速读写,应用一旦需要,立刻就能让出来。available 已经把“可回收的缓存”算进去了,它才代表真正还能给应用用多少。所以判断内存够不够,看 available。free 小、available 大,完全正常——这恰恰说明 Linux 把内存利用得很充分。
swap 是“拿磁盘当内存的延伸”。物理内存不够时,系统把不活跃的内存页挪到 swap。
vmstat 1 看 si/so 两列,如果它们持续不为 0,说明系统在“内存和磁盘之间反复倒腾”,这会让性能急剧下降——这叫 swap 抖动(thrashing)。判断标准:看趋势和活动度,不是看“有没有用 swap”。
当物理内存和 swap 都用光,内核会启动 OOM killer,按一套评分挑一个进程直接杀掉来自救。如果一个服务“莫名其妙就没了”,日志里又没有它自己的崩溃信息,一定要查 OOM:
journalctl -k | grep -i oom
dmesg | grep -i oom看到 Out of memory: Killed process ...,就坐实了是内存耗尽。OOM 是“内存真不够”最硬的证据——和“free 看着少”完全是两码事。
free -h 看 available —— 是不是真的紧张,还是只是缓存多。ps aux --sort=-%mem | head —— 谁在吃内存,看 RSS。vmstat 1 —— swap 在不在频繁抖动。journalctl -k | grep oom —— 有没有发生过 OOM。把这几步走完,你能说清“内存到底有没有问题、是谁的问题”,而不是凭 free 的一个数字下结论。
别手动 drop_caches“释放内存”
网上常见的 echo 3 > /proc/sys/vm/drop_caches“清理内存”是个误区——你只是把有用的缓存丢了,系统接下来还得重新从磁盘读,反而变慢,内存也很快又被缓存填回去。缓存不是“浪费”,是优化。真正内存紧张时,该做的是找出吃内存的进程、优化它或加内存,而不是清缓存。同理,盲目关 swap、或随便调 swappiness,在不理解的情况下也可能让情况更糟。
| 误区 | 更稳妥的做法 |
|---|---|
看 free 小就以为内存不够 | 看 available,它才算上了可回收的缓存 |
| 把 buff/cache 当成“被浪费的内存” | 缓存是优化,应用要用随时能回收 |
| 看到有 swap 占用就判定故障 | 看 vmstat 的 si/so 趋势,频繁抖动才是问题 |
| 用 drop_caches 手动“释放内存” | 没意义还更慢;真紧张就找吃内存的进程 |
版权归属:Shuo Liu