作者 / 尝君、品文
编辑 / 芹菜
出品 / 云巅论剑
青囊，喜欢运动T恤加皮裤的非典型程序猿。此时，他正目不转睛注视着屏幕上一行行的代码，内存泄漏这个问题已经让他茶饭不思两三天了，任凭偌大的雨滴捶打着窗户也无动于衷。就这么静悄悄地过了一会儿，突然间，他哼着熟悉的小曲，仿佛一切来的又那么轻松又惬意。
是谁，在撩动我琴弦，那一段被遗忘的时光......
初识内存泄漏
小白的练级之路少不了前辈们的语重心长。从踏上linux内核之路开始，专家们就对青囊说——“遇到困难要学会独立思考”、“最好的学习方式就是带着问题看代码”等等。可这次遇到的问题，让青囊百思不得其解——机器总内存有200G,运行800多天，slabUnreclaim占用 2G，且停掉业务进程，内存占用并没有降低。客户非得让青囊给出合理解释：
1.slab 2G内存是否存在泄漏？如果存在泄漏需要找到原因。
2.如不存在泄漏，需要找到这2G的使用者。
客户的问题很毒辣，是或不是都得给出合理解释，需要用数据说话。带着这些疑问，青囊开始了漫长的排查之路。
正在青囊全身心投入工作的时候，专家走到他的身旁，静悄悄的脚步并没有被专心致志的青囊发现。专家的眼光放在了那一串串的代码之上，眼里流露出老父亲般的慈祥。专家张口一句：“内存泄漏，这类问题不难，内核自带kmemleak可以排查。况且200G的内存，slab Unreclaim才占用2G，这根本就没问题嘛。”青囊一下子抓到了救命稻草，眼里泛着希望的光芒。
一来这可能不是一个问题，二来也有排查工具kmemleak了。说干就干，青囊对kmemleak原理和使用进行了深入学习，kmemleak的使用总结起来就两条指令:
echo scan > /sys/kernel/debug/kmemleak
cat /sys/kernel/debug/kmemleak
青囊迫不及待地登陆服务器执行命令——
#echo scan > /sys/kernel/debug/kmemleak
bash: /sys/kernel/debug/kmemleak: Permission denied
咦，居然提示没权限？
#ls -l /sys/kernel/debug/kmemleak
ls: cannot access /sys/kernel/debug/kmemleak: No such file or directory
查看系统配置，原来线上环境根本就没有打开kmemleak。
# CONFIG_DEBUG_KMEMLEAK is not set
青囊立马想到，可以重新编译内核使能kmemleak，再让客户来复现问题，但客户狠狠地甩了一句，“你们的目标不是提供永不停机的计算服务吗！？”
此时此刻，青囊燃起的希望又破灭了。
青囊自我安慰了一番，接着跑到专家边上想请教。他一脸沮丧地说着问题背景，专家听罢，无可奈何地挥了挥手：“你玩斗地主都是直接上来就王炸的吗？这种问题应该是自己思考解决的”。青囊只好灰头土脸地回工位。痛定思痛，他憋着口气，一定要搞懂内存管理，搞懂slab内存分配。
于是，青囊又开始了自己的钻研之路。
内存泄漏升华之路
经过系统学习，青囊对内存管理有了大致的了解。按照Linux 内存分配API的不同，可以把内存简单分为四种类型——
alloc page 内存， 直接调用__get_free_page/alloc_pages等函数从伙伴系统申请单个或多个连续的页面。
slab 内存，使用kmalloc/kmem_cache_alloc 等slab接口申请内存。slab 分配器基于伙伴系统，提供了小内存的分配能力(虽然也兼容大内存分配)。slab分配器从伙伴系统"批发"大内存，然后把大内存分成许多小块内存，一个小块内存块称为object, 最后把object "零售"给其他内核组件使用。
vmalloc内存，vmalloc内存也是基于伙伴系统，实现了线性映射非连续内存的能力，能够分配更多，更大的内存。
用户态内存，主要指anon page 和file cache，最终由内核一个个单一的页面映射而成。
青囊不知道自己这样的理解到底属于什么程度，于是想借着客户的问题，顺便也动手练习一下。虽然内存的使用进程成千上万，但作为物理存储介质，不管内存被哪个进程使用，物理上都是不可移动的。泄漏的内存是“躺尸”一样的存在，而且特征还非常明显。因为泄漏的slab内存，就好比聚会后的场地，总会留下点什么。
其特点有——
内存的内容不会再改变, 因为没有进程能访问到这块内存。
slab的object内存对象，可能会残留使用过的全局变量, 函数名，字符串，指针，特定数值(垃圾满地)。
内存中充斥着大量内容相似（相等）的slab object对象。
基于以上三个特征，青囊这里也借助“大数据”思维来进行排查，可以使用crash工具在内存中寻找出现最多的object，并且在object中找到可视的函数名，全局变量，再结合代码，就可以推测泄漏的函数了。
sysAK——内存泄漏无处遁逃
有了slab分配器系统的学习，以及对内存泄漏特征的思考，等到再一次登陆机器时，青囊信心满满志在必得。想想毕竟有备而来，这次一定让内存泄漏无处可逃。
排查过程大致可以分为四步：
1. 确认泄漏的slab
通过slabtop -s -a ，找到使用objects最多且不可回收的slab
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 419440512 419440512 100% 0.03K 3276879 128 13107516K kmalloc-32 810303 401712 49% 0.10K 20777 39 83108K buffer_head 417600 362397 86% 1.05K 13920 30 445440K ext4_inode_cache 267596 241915 90% 0.57K 9557 28 152912K radix_tree_node 216699 154325 71% 0.19K 10319 21 41276K dentry 155958 37367 23% 0.04K 1529 102 6116K ext4_extent_status
可以看到kmalloc-32的active object达到了4亿多个，占用内存在1.3G左右，泄漏嫌疑最大，那就拿kmalloc-32来开刀了。
2. 启用crash实时分析kmalloc-32的内存
3.查找kmalloc-32内存页
crash> kmem -S kmalloc-32 | tailffffea000c784e00 ffff88031e138000 0 128 111 17ffffea00242d0240 ffff88090b409000 0 128 126 2ffffea00436c5800 ffff8810db160000 0 128 127 1ffffea0018b1df40 ffff88062c77d000 0 128 126 2ffffea005947d1c0 ffff881651f47000 0 128 126 2ffffea004d463080 ffff8813518c2000 0 128 126 2ffffea0030644100 ffff880c19104000 0 128 126 2
4.dump内存内容
这里可以随机选择多个page来分析，这里选择ffff88031e138000来分析。
crash> rd ffff88031e138000 -Sffff88031e138000: ffff882f59bade00 dead000000100100 ...Y/...........ffff88031e138010: dead000000200200 ffffffff002856f7 .. ......V(.....-------ffff88031e138020: ffff882f59bade00 dead000000100100 ...Y/...........ffff88031e138030: dead000000200200 ffffffff00284a2a .. .....*J(.....------ffff88031e138040: ffff882f59bade00 dead000000100100 ...Y/...........ffff88031e138050: dead000000200200 00303038002856f7 .. ......V(.800.------ffff88031e138060: ffff882f59bade00 dead000000100100 ...Y/...........ffff88031e138070: dead000000200200 ffffffff00284a29 .. .....)J(.....
可以看到每个object的内容大体相似，但并没有预期的顺利，没有看到函数名或者变量名，可青囊知道 ffff882f59bade00 这也是个slab内存地址，于是进一步打印其内容
crash> x /20a 0xffff882f59bade000xffff882f59bade00: 0x460656b7 0xffffffff81685b60 0xffff882f59bade10: 0x63ea63ea00000001 0xffff882f59bade180xffff882f59bade20: 0xffff882f59bade18 0x00xffff882f59bade30: 0x0 0xffff882f59bade380xffff882f59bade40: 0xffff882f59bade38 0x7fb27fb2
0xffffffff81685b60明显是内核只读段的地址。sym 这个地址，原来是inotify_fsnotify_ops全局变量，从而推出泄漏结构体是struct fsnotify_event_private_data，然后结合fsnotify_event_private_data分配和释放的代码，在释放内存时存在不正确的判断逻辑，导致分配的内存没有添加到链表，失去释放的机会，从而导致泄漏。
分析到这里，青囊终于确认这是一起内存泄漏，而且泄漏的函数也定位到了，这下算是可以给客户一个满意的答案了。
客户问题得到了解决，青囊也对内存管理有了深刻的认识，还形成了自己的一套分析方法。但是青囊心里也清楚，泄漏的内存不是每次都能找到函数名或者可视字符，手工使用crash查看的内存样本也不一定够，还要对内存地址比较敏感。于是青囊想把这套分析方法提炼成工具，可以对内存泄漏这类问题实施快速一键诊断，且不要懂内存知识，人人都可以上手分析。
抱着这样的理念，实现了5个核心功能：
自动判断系统是否存在泄漏。
自动判断是slab, vmalloc还是alloc page泄漏。
扫描全局内存，找到内存中slab object最多，且内容相似度最高的object。
动态采集内存的分配和释放。
计算动态采集地址的内容与存量object的内容相似度，但达到一定相似度时，则对动态地址进行标记。
青囊把工具命名为sysAK，寓意像AK47一样，能够对系统问题快速定位。随着青囊的学习成长，sysAK后续也会加入更多的功能，实现对操作系统全方位的监控，诊断和修复。
手握sysAK，青囊也蠢蠢欲动想验证自己的工具，于是找专家们要来正在处理的“内存泄漏问题”。专家们只见青囊轻轻地敲击了一条指令sysak memleak
静静等待了200秒后，屏幕输出了令人为之一振的结果：
未释放内存汇总:次数 标记次数 函数66 62 bond_vminfo_add+0x7c/0x200 [bonding]109 0 memleak_max_object+0x3f7/0x7e0 [mem]33 0 inet_bind_bucket_create+0x21/0x701 0 copy_fs_struct+0x22/0xb01 0 tracepoint_add_probe+0xf8/0x430
slab: kmalloc-64 object地址: 0xffff88003605e000 相似object数量: 593975泄漏函数: bond_vminfo_add+0x7c/0x200 [bonding]
结果直接显示bond_vminfo_add函数存在泄漏，因为它分配的地址与内存中的59万个object高度相似。专家们看到这个结果，半信半疑地回去review代码——bond_vminfo_add函数竟然真存在泄漏。大家对青囊投来了诧异的眼神，满是赞许。
此刻的畅快，像极了游戏通关之后的感觉。通过自己的努力，最终顺利解决了问题，这个过程，只是说起来都觉得充满了成就感。这次经历，也鼓舞着青囊继续前行。
一个程序猿的自我修养——别轻易放过bug 。
（完）
往期精彩回顾
说明：本文为「云巅论剑」原创文章，转载请遵守转载要求，不允许修改内容，请务必保留作者和出处。