available才是判断内存是否充足的依据，它综合考虑了可回收缓存和安全水位；当available接近0而buff/cache居高不下时，需排查tmpfs、slab泄漏、deleted文件句柄等隐性内存占用。
这种情况很典型：top 或 ps 显示各进程 RSS 合计才几 GB，free -h 却显示 available 接近 0，系统卡顿甚至触发 OOM Killer。问题不在用户进程“明面上”的内存，而在内核管理的隐性内存消耗或不可见占用。
重点看 available 和 buff/cache 的构成
Linux 把空闲内存优先用于 page cache（文件缓存）、slab（内核对象缓存）、tmpfs/shm（内存文件系统）等。这些都计入 buff/cache，但并非全部可回收。当 available 持续走低而 buff/cache 居高不下时，说明其中一部分已固化、无法被快速释放。
- 运行 free -w 查看 buff 和 cache 是否分离——cache 高而 buff 低，大概率是页缓存堆积；cache 低但 buff 高，可能与块设备缓冲或驱动相关
- 用 cat /proc/meminfo | grep -E "Cached|SReclaimable|Shmem|Slab|PageTables|KernelStack" 定位具体哪类内核内存增长异常
- 特别关注 SReclaimable（可回收 slab）和 SUnreclaim（不可回收 slab）：若 SUnreclaim 持续上涨，可能是内核模块泄漏（如网卡驱动、加密模块）
排查 tmpfs、shm 和内存挂载点
tmpfs 是直接使用物理内存的虚拟文件系统，它不体现在进程 RSS 中，却实实在在占着内存。常见于 /dev/shm、/run、/sys/fs/cgroup 等路径。
- 执行 df -h -t tmpfs 查看所有 tmpfs 挂载点使用量，尤其注意 /dev/shm 是否被程序写满（如数据库共享内存段未清理）
- 检查 find /dev/shm -type f -ls 或 ls -lR /dev/shm，确认是否有大文件或残留匿名映射
- 查看 cgroup v1/v2 内存限制是否被突破：cat /sys/fs/cgroup/memory/memory.usage_in_bytes（v1）或 cat /sys/fs/cgroup/*/memory.current（v2）
检查内核 slab 分配与潜在泄漏
slab 是内核为频繁申请小对象（如 inode、dentry、sk_buff）预分配的内存池。正常会随压力动态伸缩，但如果某类对象持续不释放，就会形成“内存黑洞”。
- 运行 slabtop -o（按活跃对象排序），重点关注 Active / Total 比值低、Size 大且 Num Objs 持续增长的对象（如 dentry、ext4_inode_cache、UDPv6、nf_conntrack_*）
- 对比两次输出：watch -n 5 'slabtop -o | head -20'，观察哪些项在几分钟内明显增加
- 若怀疑 conntrack 泄漏，检查连接数：conntrack -C（当前条目数），并用 conntrack -L | wc -l 验证；过高需调大 net.netfilter.nf_conntrack_max 或排查长连接未关闭
验证是否存在未释放的 deleted 文件句柄
进程打开文件后删除该文件，文件内容仍驻留在内存中，直到进程关闭句柄。这类“幽灵文件”不会出现在磁盘空间统计里，但会持续占用 page cache 和 slab（如 buffer_head）。
- 执行 lsof +L1 直接列出所有被删除但仍被打开的文件（+L1 表示 link count = 0）
- 配合 lsof -nP | grep deleted | awk '{print $2}' | sort -u 提取对应 PID，再用 ps -p PID -o pid,comm,args 定位具体进程
- 常见场景：日志轮转未重载（logrotate 后服务未发 HUP）、监控 agent 持有旧日志句柄、容器 runtime 清理不彻底
