内核态泄漏需看Slab与SUnreclaim同步持续上涨且MemAvailable下降；若SReclaimable占比超80%则多为可回收缓存，非泄漏；KernelStack突增则提示栈溢出而非slab泄漏。
直接看 /proc/meminfo 里的 Slab 和 SUnreclaim，如果这两项持续上涨而 MemAvailable 同步下降，基本就是内核空间没释放导致的异常占用。
怎么区分是缓存还是真泄漏
Linux 的“高内存占用”不等于“泄漏”。关键看三组数字是否同步变化：
-
MemAvailable持续掉，Slab持续涨 → 内核态泄漏嫌疑极大 -
Slab高但SReclaimable占比超 80% → 大概率是可回收缓存（如 dentry、inode），不是泄漏 -
KernelStack突增或波动剧烈 → 可能是内核栈溢出或递归过深，不是 slab 泄漏
执行一次快照对比最直观：
watch -n 5 "grep -E 'MemAvailable|Slab|SReclaimable|SUnreclaim|KernelStack' /proc/meminfo"
盯住 SUnreclaim：它代表 slab 中**不可回收**的部分，只要它每分钟稳定增长几十 KB 以上，就该拉响警报。
定位具体哪个 slab 缓存在吃内存
/proc/slabinfo 是唯一可信来源，但原始输出太乱。用这个命令按“未释放对象数”排序：
awk '$2 > $3 {print $1, $2-$3, int($2/$3*100)/100}' /proc/slabinfo | sort -k2 -nr | head -10
重点关注：
-
kmalloc-*系列（如kmalloc-2048）→ 通用内存池，驱动或模块分配后忘 free 的高发区 -
nf_conntrack_*→ 连接跟踪表泄漏，常见于高并发短连接场景 -
dentry/inode_cache→ 如果SReclaimable同步高，先别急着判泄漏，可能是目录遍历或 unlinked 文件残留
注意：单次输出意义不大，必须间隔 5–15 分钟采两次，算差值。比如 kmalloc-4096 从 12000 → 12800，说明 10 分钟新增了 800 个未释放对象。
确认是不是 kmemleak 能抓到的泄漏
如果内核编译时启用了 CONFIG_DEBUG_KMEMLEAK（多数云厂商定制内核已开），可以直接用 kmemleak 扫描：
先确保 debugfs 已挂载：
mount -t debugfs nodev /sys/kernel/debug/
触发一次扫描并查看结果：
echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak | head -20
如果看到类似这样的输出：
unreferenced object 0xffff888123456000 (size 256):
comm "ksoftirqd/0", pid 9, jiffies 4321098765
backtrace:
[<ffffffff811a2b3c>] kmemleak_alloc+0x4c/0xb0
[<ffffffff812b3f1e>] kmem_cache_alloc+0x1fe/0x2f0
[<ffffffffc0abcdef>] my_driver_rx_handler+0x8a/0x120
说明泄漏点已定位到具体模块和函数（比如 my_driver_rx_handler）。但要注意：kmemleak 默认每 10 分钟自动扫一次，且早期分配可能进不了日志——所以发现异常后第一时间手动 echo scan，别等。
容易被忽略的硬伤
很多排查卡在最后一步：你以为锁定了 kmalloc-1024，但重启模块后它还在涨。这时候要检查三点：
- 该缓存是否被多个模块共用？比如网卡驱动和 iptables 模块都调
kmem_cache_alloc，得结合slabinfo的name列和模块加载顺序交叉验证 -
slabinfo第 4 列（objsize）是否和你怀疑的结构体大小吻合？比如你查struct sk_buff，它的典型大小是 224 字节，对应缓存名往往是skbuff_head_cache，不是kmalloc-256 - 有没有用户态程序通过
ioctl或sysfs接口反复触发内核分配？比如某些监控 agent 会高频读取/sys/class/net/*/statistics，间接导致ethtool相关缓存膨胀
