linux 中 slab 占用过高需先用 slabtop 和 /proc/meminfo 定位热点对象（如 dentry、inode_cache），再通过 drop_caches 或调高 vfs_cache_pressure 临时缓解，最终应从应用行为、文件系统配置及内核参数协同根治。
Linux 中 slab 占用过高，通常意味着内核对象缓存（如 inode、dentry、buffer_head 等）堆积过多，可能引发内存压力、OOM 或系统响应变慢。关键不是盲目清理，而是定位根源并针对性优化。
确认 slab 真实占用和热点对象
先用 slabtop 实时查看排序（按 c 键按缓存大小排序），重点关注 Active / Total 比值低、Obj/Slab高、Size大的缓存项，比如：
– dentry（目录项缓存）
– inode_cache（inode 缓存）
– ext4_inode_cache 或 xfs_inode
– buffer_head
再结合 cat /proc/meminfo | grep -i slab 看总 slab 内存（SReclaimable + SUnreclaim），若 SUnreclaim 持续偏高，说明部分缓存无法回收（如被进程长期持有引用）。
释放可回收的 slab 缓存
仅适用于临时缓解，不解决根本问题：
– 清理 pagecache、dentries 和 inodes（三者联动）：
echo 2 > /proc/sys/vm/drop_caches
（注意：需 root 权限；不会影响正在使用的缓存，只释放“干净且无引用”的对象）
– 单独触发 dentry/inode 回收（更安全）：
echo 1 > /proc/sys/vm/vfs_cache_pressure（默认 100，调高至 150~200 可加快回收）
echo 1 > /proc/sys/vm/zone_reclaim_mode（配合 NUMA 场景，慎用）
从文件系统与应用层根治
slab 膨胀多由上层行为驱动，需协同优化：
– 关闭不必要的自动挂载（autofs）、NFS 长连接、大量小文件遍历脚本
– 应用避免频繁 open/close 同一类文件，复用 fd，减少 dentry/inode 生成
– ext4/xfs 等文件系统启用dir_index 和filetype（提升 dentry 查找效率，间接降低缓存压力）
– 容器环境检查是否共享宿主机 /proc 或 /proc/sys/fs/inotify，inotify 实例过多会显著增加 dentry 消耗
内核参数微调（谨慎操作）
修改前务必备份原值，测试验证：
– 限制单个进程可创建的 dentry/inode 数量（防滥用）：
echo 65536 > /proc/sys/fs/dentry-state（非标准接口，实际通过 vfs_cache_pressure 调控）
– 调整回收倾向：
sysctl -w vm.vfs_cache_pressure=180（值越高，越激进回收 dentry/inode）
– 控制 slab 分配器行为（仅限特定场景）：
echo 1 > /sys/kernel/slab/*/shrink（对指定 slab 缓存手动触发收缩，需确认缓存名）
slab 优化本质是平衡缓存效率与内存开销，重点在识别异常模式而非压制指标。多数情况下，查清哪个服务 / 挂载点 / 脚本持续申请对象，比调参更有效。
