关键看 available 列而非 used，它才是系统当前真正可用内存估算值；si/so 持续大于 0 表明物理内存严重不足，需结合 vmstat 与 /proc/meminfo 交叉验证。
free 命令怎么看才不被 buff/cache 迷惑
很多人看到 free -h 输出里 available 很小、used 却很高，就以为内存快爆了——其实这是对 linux 内存管理机制的典型误读。Linux 会把空闲内存尽可能用于 buff/cache（缓存磁盘块和文件页），这部分内存随时可被进程回收，不等于“被占用”。关键看 available 列，它才是系统当前真正可用的内存估算值。
实操建议：
- 始终加
-h（人类可读）和-w（宽输出，避免截断available列）：free -hw - 别信
used / total算出来的“使用率”，那是过时的 windows 式理解 -
available持续低于 100MB（小内存机器）或低于总内存 5%（大内存），才值得警惕 - 如果
available正常但程序 OOM，问题大概率不在物理内存，而在 cgroup 限制、ulimit 或内存碎片
vmstat 1 能看出什么真实压力
vmstat 的核心价值不是看内存总量，而是观察内存子系统是否在“疲于奔命”。重点盯住 si（swap in）、so（swap out）、bi（block in）、bo（block out）和 cs（context switch）这几列，它们暴露的是内存短缺引发的连锁反应。
常见错误现象：
-
si和so持续 > 0 → 进程正在频繁换入换出，说明物理内存严重不足，swap 成了瓶颈 -
bi/bo高 +si/so也高 → 缓存失效严重，磁盘 I/O 和 swap 同时承压，响应延迟必然升高 -
cs突增且伴随r（runnable）队列拉长 → 内存紧张导致进程反复等待页回收或锁，调度开销暴涨
正确用法：vmstat 1 5（每秒采样，共 5 次），避开瞬时抖动；长期监控建议用 vmstat 5，避免日志爆炸。
free 和 vmstat 数据对不上？原因在这儿
free 显示的 buff/cache 和 vmstat 的 bi/bo 数值没有直接换算关系，因为：
-
free的buff/cache是当前驻留内核的缓存总量，静态快照 -
vmstat的bi/bo是每秒实际发生的块设备读写量，动态速率 - 一个大文件顺序读可能让
bi短时飙升，但buff/cache只增不减；而大量随机小写可能bo高但buff/cache变化不大（因为 page cache 被绕过或快速回写） -
vmstat不显示 swap 使用量，free也不反映页面换入换出频率——必须两者交叉验证
例如：free 显示 available 有 2GB，但 vmstat 1 中 si 持续为 1500 KB/s → 说明有进程在持续申请内存并触发直接回收，内核正把 cache 里的冷页踢出去腾地方，表面“够用”，实则已临界。
实战中容易被忽略的三个细节
很多分析卡在半路，是因为漏掉了这些底层事实：
-
/proc/meminfo中的MemAvailable才是free命令available列的原始来源，它基于PageCache、SlabReclaimable和预计可回收比例动态计算，不是简单相加 -
vmstat的swpd列只显示当前 swap 使用量（KB），但不告诉你哪些进程在用 swap ——得配合ps aux --sort=-%mem | head -10和cat /proc//status | grep VmSwap - 容器环境（如 docker）下，
free显示的是宿主机视角，而容器内看到的available可能被 cgroup memory limit 截断，此时必须查cat /sys/fs/cgroup/memory/memory.usage_in_bytes和memory.limit_in_bytes
内存分析不是比谁看得更全，而是比谁问得更准：你到底想确认“有没有足够内存启动新服务”，还是“为什么某个 java 进程 GC 时间突然变长”——问题不同，free 和 vmstat 的解读权重就完全不同。