free -h 的 available 值才是真实可用内存余量，free 列因忽略可回收缓存而严重失真；memavailable 是 /proc/meminfo 中唯一可信指标，但真实瓶颈常藏于 slabunreclaimable 或未释放共享内存。
free -h 是最直接、最可靠的起点——它给出的 available 值，才是你真正能拿来启动新进程的内存余量。别盯着 free 列看，那个值在现代 Linux 上严重失真。
为什么 free 命令的 free 列不能信
Linux 会把大量空闲内存自动用于 buffers 和 cache（如文件页缓存、slab 对象），这部分内存随时可被回收，所以它不是“被占用”，而是“被暂存”。free 命令第一行的 free 字段只统计完全未分配的内存，忽略所有可回收缓存，导致数值偏低、误导性强。
关键要看第三行（-/+ buffers/cache）或更推荐的 available 列（free -h 默认显示）：
-
available是内核估算的、无需触发交换即可供新应用使用的物理内存，综合了MemFree+ 可回收PageCache+ 部分Slab等 - 如果
available持续低于总内存的 5%～10%，才需警惕真实内存压力 -
MemAvailable字段在/proc/meminfo中也存在，和free输出的available数值一致
查哪个进程吃内存：用 ps 比 top 更准
top 按 %MEM 排序容易误判——它按“占总内存百分比”算，小内存机器上一个 50MB 进程可能显示 8%，而大内存机器上 200MB 进程才显示 2%，掩盖真实开销。
更稳的方式是用 ps 直接看绝对物理内存用量（RSS）：
ps aux --sort -rss | head -n 10
或更精细地看每个程序的独占内存（排除共享库干扰）：
- 装
ps_mem（非系统自带，需pip install ps_mem）：sudo ps_mem -s
- 输出按
PSS（Proportional Set Size）排序，即进程独占内存 + 共享内存均摊值，比RSS更反映真实资源归属 - 特别适合识别 Java、Python 等多进程/多线程服务的真实内存 footprint
/proc/meminfo 里哪些字段真有用
cat /proc/meminfo 信息全但杂，日常只需盯住这几个字段：
-
MemTotal：实际可用总内存（BIOS/内核预留后），不是dmidecode -t memory显示的插槽容量 -
MemAvailable：同free的available，唯一可信的“还能用多少”指标 -
Buffers+Cached+SReclaimable：加起来≈可快速释放的缓存量；若它们很大但MemAvailable很小，说明有不可回收内存堆积（比如SlabUnreclaimable过高） -
Shmem：tmpfs 和共享内存总量，超大值可能意味着用户创建了巨型 ramdisk 或未清理的 POSIX 共享内存段 -
HugePages_Free/HugePages_Total：若非数据库或 DPDK 类应用，出现非零值要查是否被恶意配置或泄漏
当 available 很低，但找不到大进程？查 slab 和 page cache
常见陷阱：ps 和 top 都看不到明显大户，free 却报警——问题往往出在内核内部内存池。
先运行：
slabtop -o
重点关注：
-
Active / Total列占比长期 >95% 的 slab（如ext4_inode_cache、dentry、inode_cache），可能因大量小文件或 NFS 挂载导致 -
kmalloc-*类 slab 持续增长，暗示内核模块或驱动有内存泄漏 - 对比
cat /proc/meminfo | grep "S[l]ab"中的SReclaimable和SUnreclaim：后者过高（尤其 >500MB）且不下降，基本确认 slab 泄漏
此时 echo 2 > /proc/sys/vm/drop_caches 只能清 PageCache，对 Slab 无效；必须定位并重启对应模块或服务。
MemAvailable 是唯一值得信任的“还能用多少”数字，但它只是估算值；真正的瓶颈常藏在 SlabUnreclaimable 或未释放的共享内存里——这些地方，free 和 top 都不会告诉你。
