Kernel里申请的memory常用的一般两种一种是slab(使用kmalloc等申请)一种是伙伴系统alloc_pages。当怀疑系统存在内存泄露时一般会先周期性show meminfoslabinfobuddyinfo命令如下:cat /proc/meminfocat /proc/slabinfocat /proc/buddyinfo在meminfo信息中若MemAvailable持续下降且SUnreclaim一直持续增加且业务停止后也没有下降则可怀疑出现slab申请后未释放的情况若MemAvailable持续下降但SUnreclaim没有持续增加则有可能是使用的alloc_page等申请的内存没有free。如果出现SUnreclaim一直持续增加那么应该查看slabinfo看下是否是哪个slab成员在持续增加如果有则怀疑是该slab出现了内存泄露的情况那可以打开CONFIG_SLUB_DEBUG_ON和CONFIG_SLUB_DEBUG并且检查CONFIG_DEBUG_FS是开的然后修改dts中的内核启动bootargs在bootargs中增加slub_debugu,kmalloc-xxx(需要denug的slab)然后周期性cat /sys/kernel/debug/slab/kmalloc-xxx/alloc_tracescat /sys/kernel/debug/slab/kmalloc-xxx/free_traces如果SUnreclaim在持续增加但是slabinfo里面的节点并没有看到有在持续增加那么可以考虑是使用kmalloc分配了超过了8k的大小的内存了当使用kmalloc去申请大于KMALLOC_MAX_CACHE_SIZE(一般是8k大小)的时候kmalloc会走__kmalloc_large_node函数的流程会直接调用到alloc_page函数这部分内存会算在SUnreclaim里但是没有在slabinfo的节点中针对这种情况我们需要使用pageowner来进行下一步debug开pageowner需要开CONFIG_PAGE_OWNER启动后下发命令开启:echo 1 /sys/kernel/debug/page_owner/enable然后测试过程中周期性读:cat /sys/kernel/debug/page_owner /mnt/data/xx.txt在怀疑出现内存泄露的时候把最开始抓的page owner的log和最后一次的page owner的log做对比看是哪些调用栈申请了内存没有释放增长得比较多的。可以使用page_owner_sort工具来整理前面的page owner的log 命令如下:./page_owner_sort --cull name,ator,stacktrace page_owner_begin.txt page_owner_begin_sort.txt./page_owner_sort --cull name,ator,stacktrace page_owner_end.txt page_owner_end_sort.txtpage_owner_sort会帮助我们统计每个调用栈一共分配了多少内存通过比较前后两个pageowner的log我们就能找到哪些调用栈申请了内存但没有释放。除此之外我们还能使用kmemleak来扫描看有没有内存泄露但是kmemleak自己占用的内存也比较多所以有时在小内存系统中不太友好有可能还没打到内存泄露就因为kmemleak占用太多内存而oom了。使用kmemleak步骤如下:1.打开CONFIG_DEBUG_KMEMLEAK使用kmemleak来定时扫描;2.手动触发扫描命令如下:echo scan /sys/kernel/debug/kmemleak3.查看扫描报告:cat /sys/kernel/debug/kmemleak