available列才是真实可用内存，它已扣除不可回收slab和难释放page cache并预估可回收量；cached和buffers是否算可用取决于具体使用场景。
free 命令输出里 cached 和 buffers 到底算不算“可用内存”
算，但得看怎么用。Linux 的 free 默认显示的 available 列才是你真正能指望的空闲内存——它已经扣除了内核不可回收的 slab、page cache 中难以快速释放的部分，还预估了文件缓存可回收量。而老版本（free from procps-ng available，只给 cached 和 buffers，这时候直接拿它们加总当“空闲”，大概率会误判。
常见错误现象：free -h 显示 available 只有 1.2G，但 cached + buffers 加起来有 8G，于是以为系统“明明还有大量缓存没释放”，结果一跑新进程就 OOM。
-
available是内核通过meminfo中MemAvailable:字段直接提供的估算值，比手动加减更靠谱 - 如果系统太老（比如 CentOS 6），
/proc/meminfo根本没有MemAvailable:行，此时只能保守参考free的free列（即真正未分配页框），别碰cached -
cached包含 page cache 和部分 slab（如 dentries/inodes），不是全都能立刻腾出来；buffers主要是块设备层的临时页，量通常很小
/proc/meminfo 关键字段含义与读取时机
别信 cat /proc/meminfo 一次性快照——某些字段是瞬时统计，比如 Active(file) 和 Inactive(file) 会随页面回收周期波动；而 MemTotal、MemFree 是稳定值。想准确分析内存压力，得结合多个字段交叉验证，不能只盯一个数。
使用场景：排查 Java 应用频繁 GC 却 free 显示内存充足，或容器内 RSS 暴涨但宿主机 free 看不出异常。
-
MemAvailable:最关键，对应free的available列；缺失该行说明内核 -
Active(anon)和Inactive(anon)反映匿名页活跃度，对判断 swap 倾向很重要；SwapCached:非零说明刚换入的页又被改写过，可能触发重复 IO -
SReclaimable:属于 slab 中可回收部分（如 dentry、inode 缓存），计入cached，但echo 2 > /proc/sys/vm/drop_caches才能清，echo 1不清它
free -h 输出单位混淆导致的误读
free 默认用人类可读单位（-h），但 KiB/MiB/GiB 是二进制前缀（1024 进制），而有些监控脚本硬编码 1000 进制换算，导致数值差 2.4%。更麻烦的是，free 在不同版本中对“已用内存”的计算逻辑微调过：早期把 Shmem:（tmpfs/shm）算进 used，后来版本改算进 cached ——这会影响你写告警阈值时的基准。
本书以培养高级网站建设与管理人才为目标，内容循序渐进，由浅入深，通过大量的实例系统全面地介绍了Linux+PHP+MySQL环境下的网络后台开发技术。本书详尽分析了近30个典型案例。包括计数器、网站流量统计、留言板、论坛系统、聊天室、投票与调查、用户管理、新闻发布系统、广告轮播、购物系统等等，力求让读者通过对案例的学习，轻松掌握PHP和MySQL的编程精要，迅速掌握网络后台开发技巧。 本书适
常见错误现象：用 awk '{print $3/$2*100}' 算 “内存使用率”，结果在 Ubuntu 20.04 和 CentOS 7 上同一台机器跑出两个不同数字。
- 永远用
free -b（字节）做自动化解析，避免单位歧义；-h只用于人工查问题 -
used列 =MemTotal - MemFree - Buffers - Cached - SReclaimable（近似），但内核实际算法更复杂，所以别自己手算“可用率” - 容器环境注意：
free显示的是宿主机视角，cgroup v2 下需看/sys/fs/cgroup/memory.max和/sys/fs/cgroup/memory.current
为什么 drop_caches 后 free 不见涨，/proc/meminfo 却变了
因为 echo 3 > /proc/sys/vm/drop_caches 只清 page cache、dentries 和 inodes，不碰 slab 中不可回收部分（如 SUnreclaim:）、不释放匿名页、也不影响 MemFree: ——它只是把 PageCache 和 SReclaimable: 对应的内存标记为可回收，是否立刻归还给 MemFree:，取决于内核后续有没有触发直接回收（direct reclaim）或后台回收（kswapd）。
性能影响：强制 drop 可能引发短时 IO 尖峰（尤其 echo 3 时刷脏页），且之后首次访问文件会变慢；生产环境除非调试，否则别定期 cron 它。
- 执行后重点看
/proc/meminfo中Cached:和SReclaimable:是否下降，而不是盯着free的free列 -
MemFree:不涨 ≠ 没效果；只要MemAvailable:上升了，说明内核已更新可回收估算 - 如果
drop_caches后MemAvailable:几乎不变，说明当前内存压力主要来自匿名页（Active(anon)高）或不可回收 slab（SUnreclaim:高），得查进程 RSS 或 slabtop
内存分析真正的难点不在读数，而在理解哪些字段反映真实压力、哪些只是历史快照。比如 MemAvailable: 是估算值，pgpgin/pgpgout 是累计 IO 量，pgmajfault 才暴露缺页代价——这些字段之间的关系，比单个数字本身更值得花时间对齐。
