应检查/proc/meminfo中Slab与SReclaimable是否持续增长，并用slabtop定位size-4096等热点缓存，结合trace-cmd跟踪kmalloc/kfree匹配性，必要时启用kmemleak或page_owner。
怎么看进程是否在内核态吃掉大量内存
直接看 /proc/[pid]/status 里的 KernelStack 和 Threads 没用——它们只反映线程栈开销，不包括驱动、模块或内核分配的 slab/page。真正要盯的是进程触发的内核内存行为：比如它调用了哪些系统调用（read/write/ioctl）、加载了什么内核模块、有没有频繁读写 /proc 或 /sys 接口。一个用户进程本身不“拥有”内核内存，但它能持续申请并让内核长期持有（例如缓存、等待队列、socket backlog），最终体现为 Slab 或 PageTables 增长。
查 Slab 分配暴增：先定位 size-4096、kmalloc-4k 这类热点
内核泄漏最常见于固定大小的 slab 缓存，尤其是 size-4096（对应 kmalloc(4096)）和 kmalloc-4k。这类泄漏往往藏在 procfs 接口（如 /proc/schedstat）、网络协议栈或自定义驱动里。
- 实时观察：
slabtop -o | grep "size-4096\|kmalloc-4k"，看OBJS和ACTIVE是否随时间单向上涨 - 对比快照：
cat /proc/slabinfo > slab_before→ 做操作 →cat /proc/slabinfo > slab_after→diff slab_before slab_after - 确认泄漏方向：如果
SReclaimable在/proc/meminfo中持续增长，基本可断定是 slab 可回收内存没被释放
用 trace-cmd 跟踪 kmalloc/kfree 不匹配对
当怀疑某个进程在内核中反复 kmalloc() 却漏掉 kfree()，就得抓运行时调用栈。别用 perf —— 它对 slab 分配事件支持弱；trace-cmd 是更稳的选择，尤其配合 -e kmem:kmalloc -e kmem:kfree。
- 启动跟踪（只捕获 4096 字节分配）：
trace-cmd record -e kmem:kmalloc -e kmem:kfree --filter "bytes == 4096" -T - 跑几分钟后
Ctrl+C，再执行trace-cmd report | grep -E "(kmalloc|kfree).+ptr=0x" - 重点检查：同一
ptr地址出现kmalloc但没对应kfree；多个kmallocptr 都指向相似内容（比如全是/proc/schedstat输出片段），说明是某 proc 接口实现漏释放
启用 kmemleak 或 page_owner：内核级泄漏必须开 debug 选项
kmemleak 和 page_owner 不是“装上就能用”的工具——它们依赖内核编译时打开特定配置，且需挂载 debugfs。线上环境若没提前准备，临时开启等于重启内核。
- 必须满足：
CONFIG_DEBUG_KMEMLEAK=y+CONFIG_DEBUG_FS=y，启动参数加kmemleak=on - 运行时启用：
mount -t debugfs nodev /sys/kernel/debug/，然后echo scan=10 > /sys/kernel/debug/kmemleak - 更底层的
page_owner（用于追踪alloc_pages类未统计内存）还需CONFIG_PAGE_OWNER=y和启动参数page_owner=on；导出后必须用page_owner_sort工具解析，原始/sys/kernel/debug/page_owner文件人类不可读
真正容易被忽略的点：kmemleak 默认扫描间隔是 600 秒，压测时设成 10 秒反而可能掩盖低频泄漏；而 page_owner 开启后会显著拖慢内存分配路径——它只适合复现阶段，绝不能常驻生产。
