SUnreclaim持续上涨且超总内存10%或占Slab总量90%以上才是内核slab泄漏核心信号；需先通过/proc/meminfo确认增长趋势，再用slabtop定位OBJ高、USE≈100%且reclaim_account为0的kmalloc-*等缓存。
直接看 /proc/meminfo 中的 SUnreclaim 值——它才是 slab 泄漏的核心指标，不是 Slab 大就一定泄漏，而是 SUnreclaim 持续上涨、占总内存超 10% 或接近 Slab 总量时，才真正需要动手排查。
第一步：确认是否真是内核 slab 泄漏
先排除用户态干扰，再聚焦内核：
- 用
free -h和top看用户进程内存占用是否异常——如果没明显大户，但MemAvailable持续下降，就该怀疑内核 - 执行
cat /proc/meminfo | grep -E "^(Slab|SUnreclaim|MemAvailable)"，重点关注：- SUnreclaim 是否随时间稳定增长（比如每小时涨 50MB+）
- SUnreclaim / Slab 是否 > 0.9（说明几乎全是不可回收对象）
- SUnreclaim 是否 > 总内存 × 0.1（64G 机器超过 6.4G 就亮红灯）
- 对比基线：找一台同配置、未长期运行的机器，做同样检查，差值大于 1G 就值得深挖
第二步：定位高嫌疑 slab 缓存
用 slabtop -s -a 按对象数排序，盯住三类缓存：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- kmalloc-*（如 kmalloc-128、kmalloc-1024）：通用小内存分配器，驱动或模块泄漏最常藏身于此
- ext4_*（如 ext4_inode_cache、ext4_xattr）、radix_tree_node：文件系统操作频繁时易堆积，但需结合 USE 判断——若 USE ≈ 100% 且 OBJS 持续涨，就是强信号
- nf_conntrack_*、tcp_*：网络连接数激增或连接未正常关闭时可能卡住
- 别只信 ACTIVE 数：USE 为 0% 但 OBJS 很大，可能是缓存未回收而非泄漏；USE 接近 100% 且不降，才更可疑
第三步：验证是否真不可回收
查 /sys/kernel/slab/<cache_name>/reclaim_account 文件：
- 返回 0 → 该缓存对象计入 SUnreclaim，释放逻辑被绕过，泄漏可能性高
- 返回 1 → 属于可回收缓存（如 dentry），即使占用高，通常不是泄漏，只是暂未回收
- 例如：
cat /sys/kernel/slab/kmalloc-128/reclaim_account输出 0，再配合其 OBJS 持续上涨，基本可锁定
第四步：进一步追踪泄漏源头（可选但关键）
确认缓存后，要找到谁在分配却不释放：
- 启用 kmemleak（需内核编译时开启
CONFIG_DEBUG_KMEMLEAK）：echo scan > /sys/kernel/debug/kmemleak触发扫描，再cat /sys/kernel/debug/kmemleak查未引用对象及分配栈 - 用 trace-cmd 跟踪特定大小分配：
trace-cmd record -e kmalloc -f 'bytes_alloc==128' -e kfree -T，跑几分钟后trace-cmd report，看哪些 kmalloc 地址没有对应 kfree - 对嵌入式或无法重启的场景，启用 page owner（需
page_owner=on启动参数）：
压测前后分别导出/sys/kernel/debug/page_owner，用page_owner_sort工具比对调用栈变化
