内核态内存泄漏可由/proc/meminfo中MemFree持续下降、Slab（尤其SUnreclaim）异常上涨判定；用户态泄漏则表现为top中某进程%MEM持续攀升。
/proc/meminfo 持续下降的 MemFree + 高涨的 Slab（尤其是 SUnreclaim），基本可以断定是内核态内存泄漏；若 top 显示某用户进程 %MEM 持续爬升，则优先怀疑用户态泄漏——这是系统层面排查的第一判断锚点。
看 /proc/meminfo：先确认泄漏类型和范围
别一上来就跑工具。先用 cat /proc/meminfo | grep -E "MemFree|Slab|SReclaimable|SUnreclaim" 快速抓关键指标：
-
MemFree缓慢但持续减少，而Buffers/Cached变化不大 → 很可能不是缓存问题，而是真实泄漏 -
Slab占用 > 1GB 且随时间上涨 → 内核 slab 分配器泄漏嫌疑极大 -
SUnreclaim高（比如占Slab总量 90%+）→ slab 中大量对象无法被回收，典型如dentry、inode_cache、sock_inode_cache泄漏 -
PageTables或KernelStack异常高 → 可能是进程数暴增或内核线程栈未释放
⚠️ 注意：Slab 高 ≠ 一定泄漏——有些负载下 dentry 缓存会自然增长，需结合变化趋势（压测前后对比）和 slabtop 实时观察。
盯 slabtop -o：定位暴涨的 slab cache
运行 slabtop -o（-o 表示“只显示活跃缓存”，避免干扰），按 Shift + P 按大小排序，重点关注：
- 名字含
dentry、inode、sock、buffer_head、size-4096的项 - 对应行的
ACTIVE列是否远高于OBJS（说明对象长期不释放） - 反复刷新时，
ACTIVE是否稳定增长（例如每分钟 +5000）
如果看到 size-4096 活跃对象从 10 万涨到 50 万，且 NAME 列为空或为 kmalloc-4096，大概率是驱动或模块调用 kmalloc(4096) 后没配对 kfree()。
查 /proc/slabinfo 和 trace-cmd：确认分配/释放失衡
当 slabtop 锁定可疑 cache（如 dentry），进一步验证是否“只申请不释放”：
- 用
grep dentry /proc/slabinfo查当前活跃数，记下数值 A - 等 2 分钟再查，得数值 B；若 B − A > 0 且稳定增长，进入下一步
- 启用 trace：
trace-cmd record -e kmem:kmalloc -e kmem:kfree -F -p 1000
（-F前台执行，-p 1000采样精度） - 运行几分钟后
Ctrl+C，再trace-cmd report | grep "size=4096\|dentry"
? 关键线索：大量 kmalloc 的 ptr=0xffff88... 出现，但找不到对应 kfree 的同一 ptr → 实锤泄漏。此时可配合 crash 工具读取该地址内容，反推调用路径（例如发现全是 /proc/schedstat 相关字符串，就指向 kernel bug）。
别漏掉 page owner：专治 buddy 系统“黑盒泄漏”
如果 Slab 正常，但 MemFree 仍狂跌，且 /proc/buddyinfo 显示低阶页面（如 order-0）持续减少 → 很可能是模块绕过 slab，直接调用 alloc_pages() 或 __get_free_pages()，这类内存不会出现在 /proc/slabinfo 中，属于“内存黑洞”。
- 必须提前开启：
CONFIG_PAGE_OWNER=y+ 启动参数加page_owner=on - 压测前后分别导出：
cat /sys/kernel/debug/page_owner > before.txt和after.txt - 用
page_owner_sort工具分析（需自己编译）：./page_owner_sort after.txt | head -20
→ 排名靠前的调用栈就是泄漏源头
⚠️ 这个机制开销不小，仅限复现环境使用；线上慎开，且需确保 debugfs 已挂载。
内核泄漏最棘手的不是找不到工具，而是“泄漏路径藏在间接调用里”——比如一个模块注册了proc_ops，但读接口里忘了 kfree()；或者 dentry 被某个不显眼的文件系统钩子反复创建却无人销毁。所以，slabtop 和 page_owner 要搭配着用，前者筛“高频缓存”，后者兜底“直连 buddy”的黑盒。 
