内存泄漏一网打尽

青囊,喜欢运动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,再让客户来复现问题,但客户狠狠地甩了一句,“你们的目标不是提供永不停机的计算服务吗!?”

此时此刻,青囊燃起的希望又破灭了。

AK47所向披靡,内存泄漏一网打尽

青囊自我安慰了一番,接着跑到专家边上想请教。他一脸沮丧地说着问题背景,专家听罢,无可奈何地挥了挥手:“你玩斗地主都是直接上来就王炸的吗?这种问题应该是自己思考解决的”。青囊只好灰头土脸地回工位。痛定思痛,他憋着口气,一定要搞懂内存管理,搞懂slab内存分配。

于是,青囊又开始了自己的钻研之路。

内存泄漏升华之路

经过系统学习,青囊对内存管理有了大致的了解。按照Linux 内存分配API的不同,可以把内存简单分为四种类型——

  1. alloc page 内存, 直接调用__get_free_page/alloc_pages等函数从伙伴系统申请单个或多个连续的页面。
  2. slab 内存,使用kmalloc/kmem_cache_alloc 等slab接口申请内存。slab 分配器基于伙伴系统,提供了小内存的分配能力(虽然也兼容大内存分配)。slab分配器从伙伴系统"批发"大内存,然后把大内存分成许多小块内存,一个小块内存块称为object, 最后把object "零售"给其他内核组件使用。
  3. vmalloc内存,vmalloc内存也是基于伙伴系统,实现了线性映射非连续内存的能力,能够分配更多,更大的内存。
  4. 用户态内存,主要指anon page 和file cache,最终由内核一个个单一的页面映射而成。

AK47所向披靡,内存泄漏一网打尽

青囊不知道自己这样的理解到底属于什么程度,于是想借着客户的问题,顺便也动手练习一下。虽然内存的使用进程成千上万,但作为物理存储介质,不管内存被哪个进程使用,物理上都是不可移动的。泄漏的内存是“躺尸”一样的存在,而且特征还非常明显。因为泄漏的slab内存,就好比聚会后的场地,总会留下点什么。

其特点有——

  1. 内存的内容不会再改变, 因为没有进程能访问到这块内存。
  2. slab的object内存对象,可能会残留使用过的全局变量, 函数名,字符串,指针,特定数值(垃圾满地)。
  3. 内存中充斥着大量内容相似(相等)的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 | tail
ffffea000c784e00  ffff88031e138000     0    128        111    17
ffffea00242d0240  ffff88090b409000     0    128        126     2
ffffea00436c5800  ffff8810db160000     0    128        127     1
ffffea0018b1df40  ffff88062c77d000     0    128        126     2
ffffea005947d1c0  ffff881651f47000     0    128        126     2
ffffea004d463080  ffff8813518c2000     0    128        126     2
ffffea0030644100  ffff880c19104000     0    128        126     2

4.dump内存内容

这里可以随机选择多个page来分析,这里选择ffff88031e138000来分析。

crash> rd ffff88031e138000 -S
ffff88031e138000:  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 0xffff882f59bade00
0xffff882f59bade00:     0x460656b7      0xffffffff81685b60 
0xffff882f59bade10:     0x63ea63ea00000001      0xffff882f59bade18
0xffff882f59bade20:     0xffff882f59bade18      0x0
0xffff882f59bade30:     0x0     0xffff882f59bade38
0xffff882f59bade40:     0xffff882f59bade38      0x7fb27fb2

0xffffffff81685b60明显是内核只读段的地址。sym 这个地址,原来是inotify_fsnotify_ops全局变量,从而推出泄漏结构体是struct fsnotify_event_private_data,然后结合fsnotify_event_private_data分配和释放的代码,在释放内存时存在不正确的判断逻辑,导致分配的内存没有添加到链表,失去释放的机会,从而导致泄漏。

分析到这里,青囊终于确认这是一起内存泄漏,而且泄漏的函数也定位到了,这下算是可以给客户一个满意的答案了。

客户问题得到了解决,青囊也对内存管理有了深刻的认识,还形成了自己的一套分析方法。但是青囊心里也清楚,泄漏的内存不是每次都能找到函数名或者可视字符,手工使用crash查看的内存样本也不一定够,还要对内存地址比较敏感。于是青囊想把这套分析方法提炼成工具,可以对内存泄漏这类问题实施快速一键诊断,且不要懂内存知识,人人都可以上手分析。

抱着这样的理念,实现了5个核心功能:

  1. 自动判断系统是否存在泄漏。
  2. 自动判断是slab, vmalloc还是alloc page泄漏。
  3. 扫描全局内存,找到内存中slab object最多,且内容相似度最高的object。
  4. 动态采集内存的分配和释放。
  5. 计算动态采集地址的内容与存量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/0x70
1        0             copy_fs_struct+0x22/0xb0
1        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函数竟然真存在泄漏。大家对青囊投来了诧异的眼神,满是赞许。

此刻的畅快,像极了游戏通关之后的感觉。通过自己的努力,最终顺利解决了问题,这个过程,只是说起来都觉得充满了成就感。这次经历,也鼓舞着青囊继续前行。

  • 0
    点赞
  • 7
    收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:博客之星2021 设计师:Hiro_C 返回首页
评论

打赏作者

一口Linux

众筹植发

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值