应关注 free -h 输出中的 available 值而非 free 列,因为 available 才是内核估算的、无需触发 oom killer 即可立即分配的内存,包含可回收的 buff/cache,真实反映可用内存。

别看 free 输出里的 free 列——它不是你真正能用的空闲内存,多数时候这个值严重误导人。
为什么 free 命令的 free 列不准
Linux 内核会把大量“暂时不用”的内存划给 buffers 和 cache(比如文件读写缓存、目录索引等),这部分内存随时可被回收,但 free 列只统计完全没被分配的页面,不包含这些可回收缓存。所以你会看到:free 列只有几百 MB,而 available 列有几 GB——后者才是你启动新进程时实际能拿到的内存。
-
free:纯空闲页,几乎从不接近 0,不代表真实可用性 -
available:内核估算的、无需触发 OOM killer 就能立即分配的内存,含可回收缓存 -
buff/cache高 ≠ 内存紧张,反而是系统在高效利用资源
free -h 中必须盯住的字段是 available
运行 free -h 后,直接看第一行 Mem: 对应的 available 值:
在无 root/sudo 权限的环境(云容器、VPS、隔离主机)中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景:...
total used free shared buff/cache available Mem: 15G 6.2G 844Mi 1.1G 7.9G 7.4G Swap: 2.0G 256Mi 1.8G
上例中,available: 7.4G 才是你此刻能安全分配给新程序的内存。如果这个值持续低于总内存的 10%(比如 15G 总内存下
- 加
-h是必须的,避免单位混淆(KB/MB/GB) - 不要用
-m或-g硬指定单位,-h自动适配更可靠 - 容器环境或低内存设备中,
available可能被 cgroup 限制,需结合cat /sys/fs/cgroup/memory/memory.usage_in_bytes核对
当 available 值异常低时,下一步查什么
如果 available 持续偏低,说明物理内存确实吃紧,但原因未必是某个大进程——可能是缓存无法释放、内存泄漏或内核参数限制。
- 先用
ps aux --sort=-%mem | head -5快速定位内存大户 - 检查是否启用了
vm.swappiness=0:这会让内核拒绝回收缓存,导致available虚低(尤其在数据库场景) - 运行
cat /proc/meminfo | grep -E "^(MemAvailable|MemFree|Cached|SReclaimable)",确认MemAvailable与free输出一致,排除工具版本差异 -
swapon --show=USED查 Swap 是否已启用并占用——一旦 SwapUsed > 0,基本可判定物理内存已不足
真正决定系统是否“快撑不住”的,从来不是 free 列那个冷冰冰的数字,而是内核动态维护的 available 值——它背后是页回收机制、LRU 链表、cgroup 限额等一系列实时决策。盯着它,比反复刷新 top 更早发现问题。










