available字段才是当前真正能立即分配给新进程的物理内存余量，free列数值低属正常；memavailable自linux 3.14引入，动态估算可回收缓存；持续低于总内存10%或出现非零si/so即表明内存实质不足。
看 free -h 输出里的 available 字段
这才是当前真正能立即分配给新进程的物理内存余量，不是 free 那一列。Linux 内核从 3.14 开始引入 MemAvailable，它会动态估算 buffers/cache 中可快速回收的部分，比 free 值更贴近真实可用性。
执行 free -h 后，直接盯住 Mem 行的 available 列——比如显示 5.2Gi，就代表此刻约有 5.2GB 物理内存可被新服务或容器立刻使用。
-
free列数值极低（甚至为 0）是常态，不代表内存紧张；available才是判断依据 - 若
available持续低于总内存的 10%（例如 64G 机器长期 - 该值不含 swap，纯粹反映物理 RAM 的即时余量
验证 available 是否可信：对比 /proc/meminfo
free 的 available 来自 /proc/meminfo 中的 MemAvailable 字段，二者应一致。直接查原始数据可排除工具层干扰：
运行 grep MemAvailable /proc/meminfo，输出类似 MemAvailable: 5423452 kB，换算后应与 free -h 中的 available 基本吻合（允许几十 MB 误差）。
- 若两者偏差超过 5%，可能是内核版本较老（
- 此时可退而求其次，用
MemFree + Buffers + Cached - Shmem粗略估算，但不如MemAvailable可靠 - 注意：不要用
MemFree单独判断——它只计完全未使用的页，Linux 几乎不会让它高
当 available 突然变小，先查谁在吃内存
数值下降本身不说明问题，得知道谁动了这块内存。别急着 kill 进程，先定位：
运行 ps aux --sort=-%mem | head -n 11，看前 10 个进程的 %MEM 和 RSS（实际物理驻留内存）。RSS 总和接近 total - available 时，基本闭环。
- 单个进程
RSS> 2GB 且长期不降，大概率是内存泄漏或缓存未释放 - Java 进程要特别注意
-Xmx设置是否远超实际需求，它会提前占满available - 浏览器、Docker 容器、数据库（如 PostgreSQL 的 shared_buffers）常是隐形大户，需结合业务查
vmstat 1 看有没有偷偷换页
即使 available 还剩几 GB，只要开始频繁换页，物理内存就算实质不足。关键看 si（swap in）和 so（swap out）两列：
执行 vmstat 1，观察连续 5 秒内：si 或 so 是否持续 > 0（单位 KB/s）。哪怕只有 10KB/s，也说明内核正把内存页搬进搬出磁盘。
- 一旦出现非零
si/so，available数值就失去“安全余量”意义——系统已在透支 - 此时
Swap行的used值也会同步上升，free -h里能看到 - 硬盘 I/O 延迟会明显升高，
iostat -x 1中 %util 接近 100% 是佐证
最易被忽略的是：available 不是静态水位线，它随内核回收策略实时波动；而 si/so 才是内存是否真正告急的硬信号。盯着一个数不如看一组行为。
