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