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