一、内存黑洞内存泄漏分析
1.1、page owner简介
内核中通过Slab、Vmalloc、Page Cache等接口申请的内存都会被内核统计到，而直接调用alloc_pages或__get_free_pages申请的内存不会被统计而称为所谓的内存黑洞，若在这部分中出现了内存泄漏问题该如何去定位呢？Linux提供了page owner机制用来追踪谁分配的每一个页面，它可以用来调试内存泄漏或找到内存占用者。
当分配发生时，有关分配的信息，如调用堆栈和页面的顺序被存储到每个页面的特定存储中，当我们需要了解所有页面的状态时，我们可以获得并分析这些信息。
page owner特性的总体设计思路非常简单，就是通过扩展struct page结构体，增加成员变量用于存储该page被分配的调用栈及标志位，然后hack内存页的分配和释放接口，在内存页被分配时，保存调用栈信息，设置标志位，在内存页被释放时，清除调用栈信息，清除标志位，然后，通过一个debugfs的接口，将所有读取该接口时刻已经被分配出去的内存页的调用栈信息传递给用户态，并在用户态制作了一个工具，用于统计这些调用栈的信息。
下图就是page owner中统计的信息，这里需要注意的是，记录在page owner文件中的内存页都是已经被申请的，通过这些信息就可以清晰的看到内存页的调用情况。
1.2、page owner内核使能方法
page owner在默认情况下是禁用的，内核中打开page owner的流程如下：
1.2.1、使能内核宏定义
如果内核没有打开相关宏定义的话，则需要手动使能。
1.2.2、启动参数中使能
在boot cmdline中新增"page_owner=on"。
1.2.3、检测使能结果
若成功使能的话，就可以查看到/sys/kernel/debug/page_owner节点，如下图所示，
1.3、page owner分析内存泄漏流程
1、在内存泄漏问题压测前后分别使用下面的命令导出系统page owner信息，操作命令如下：
2、构建用户空间的处理工具
Linux下提供page_owner_sort工具用于处理page_owner信息，该工具可以在kernel/tools/vm/下使用make page_owner_sort命令生成，如下图所示：
3、将过滤后的page owner文件通过page_owner_sort进行排序，就可以根据页面调用次数进行排序，方便我们排查潜在的泄漏点，操作命令如下：
# grep -v ^PFN page_owner_full_before.txt > page_owner_before.txt# ./page_owner_sort page_owner_before.txt sorted_page_owner_before.txt # grep -v ^PFN page_owner_full_after.txt > page_owner_after.txt# ./page_owner_sort page_owner_after.txt sorted_page_owner_after.txt
4、打开排序后的文件查看，这里面根据每个页的申请次数进行排序，对比before、after就可以看出泄漏点。如下图，这里看到看到after中出现了5236 * 2^3 = 41888 pages的内存消耗，每个page默认是4KB，换算下就是这里有163.625 MB的内存消耗，这里只是表明这里内存消耗的比较异常，但并不一定是内存泄漏，这个还要具体去分析。
二、Slab内存泄漏分析
2.1、Slab内存泄漏定义
Linux 内核的 Slab 内存分为两块，一个是 SReclaim，另一个是 SUnreclaim，从命名就可以知道，一个是可回收的，一个是不可回收的，我们排查是否有 Slab 内存泄漏主要关注 SUnreclaim。
通过 /proc/meminfo 文件查看 SUnreclaim 数值是否有明显增大，若存在异常增加，则怀疑Slab存在内存泄漏。
2.2、Slab调试
默认情况下，slab debug是关闭的，因为这会增加内存资源的消耗，当需要调试时，可以开启下面的宏定义，
通过 /proc/slabinfo 来查看是具体哪个对象存在异常，如下图所示，
通常 Slab 的名字就表明了其用途，比如 "inode_cache"、"dentry" 什么的，根据发生泄露的 slab cache 的名字，大致就知道是哪个子系统或模块的问题，但从有些未明确命令的slab cache是无法知道的，如"kmalloc-128″ 的名称完全看不出 slab cache 的用途，因此，我们需要有方法来知道泄漏点具体的 calltrace。
2.3、内核提供的调试方法和工具
2.3.1、/sys/kernel/slab/{module}/alloc_calls
确定可能泄漏的调用栈信息可以使用如下命令查询：
alloc_calls 和 free_calls 中的调用栈信息，可以从alloc_calls中初步看出大量申请点，如下图所示：
对比alloc_calls和free_calls后找到相关怀疑点，接着使用addr2line工具在vmlinux或者对应的ko文件中查找出来具体的函数行号，从而进一步分析内存泄漏原因。
2.3.2、/sys/kernel/slab/{module}/trace
可以将申请、释放内存的调用栈信息打印到Kernel日志中，需要注意的是，开启trace可能导致系统输入输出无响应，所以，不能一直打开，只能间隔的打开一段时间，关闭操作最好放到脚本中做。
这种通过在kernel log中大量输出的calltrace的方法，在实际问题分析上使用很少，主要是分析kernel log的工作量很大，可以直接看到完整的calltrace，进而继续分析内存泄漏问题。
2.3.3、kmemleak工具
kmemleak是在 Kernel 2.6.31 中引入的工具，用于检查内存泄漏，kmemleak 可以追踪 kmalloc()，vmalloc()，kmem_cache_alloc() 等函数引起的内存泄漏，一般用于 slab 内存泄漏分析。
若要在内核中使能kmemleak工具，可以开启如下内核选项如下，
通过查询/sys/kernel/debug/kmemleak节点来检测是否成功开启了kmemleak。
kmemleak使用方法如下：
1、第一次手动scan
2、第二次手动scan
注意：若不主动scan的话，在配置kmemleak后，将会有内核线程间隔10分钟扫描一次内存，并打印找到泄漏的数量。
kmemleak 只能帮助解决一些非常简单的内存泄露问题，针对较为复杂的泄露路径，kmemleak 就无法处理了，并且 kmemleak 还存在着误检测的可能性。
尽管内核提供的这些工具和方法可以调试SLAB内存泄漏问题，但是在平时的使用中依然不够好用，重点的效率并不是很高，而当调试内存黑洞内存泄漏问题时，使用page owner可以简单快捷的定位到泄漏点，那么，slab内存泄漏问题的调试能不能也做到这个效果呢？答案是可以的，不过需要修改kernel源码来支援，这就是下一节中的slabtrace工具，现在笔者对于较复杂的slab内存泄漏问题分析都会优先使用这个工具，效率杠杠的，话不多说，开始展示！
2.4、客制化好用的调试工具 - slabtrace
先展示下slabtrace的用法和效果，如下图所示，哈哈，熟悉的味道回来了，这里可以看到操作简单，只需要在压测前后获取下slabtrace内容，接着对比查看count差异较大的点即可，而且给出了每个点的完整calltrace，calltrace level也是可以自行调整，因为有些问题点需要更深的calltrace才能看到是哪个模块出现的问题。
这里需要注意的是，slabtrace是依赖于slab debug，所以，在合入slabtrace patch时也需要使能slab debug选项。
0
