free 显示总内存 32G 而 slab 占了 14G，available 掉到 4G，业务没有大内存任务，drop_caches 能降下来又慢慢涨回去，看着像内核在漏内存，其实要先分清能不能回收。碰到这种情况，我一般先确认改动有没有真的生效。
原因不复杂，dentry 和 inode 缓存属于可回收 slab，小文件访问多时会持续增长，某些内核对象泄漏也会走 slab 而不释放，两者要分开判断，否则容易误删服务。
「slab 内存占用」这类改动最怕改一半，回滚脚本先准备好，再动生产。别只看报错的最后一行，往上看几行，真正的起因通常在上面。
sudo slabtop -o -s c | head -20 grep -E 'dentry|inode_cache' /proc/slabinfo echo 2 | sudo tee /proc/sys/vm/drop_caches free -m
同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。
具体做法是，用 slabtop 按占用大小排序看是哪个缓存占大头 名字一看就明白；对比 slabinfo 里活跃对象和总数的增长趋势 涨得快就要警惕；先 drop_caches 观察掉不掉 再判断是不是真泄漏 两次对比更可靠。
最后用这个标准收尾，drop_caches 后 slab 明显下降 一天内涨幅低于一成 业务延迟也恢复正常 连续看三天。