一次解决Linux内核内存泄漏实战全过程
Posted CSDN
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了一次解决Linux内核内存泄漏实战全过程相关的知识，希望对你有一定的参考价值。
2020 年转眼间白驹过隙般飞奔而去，在岁末年初的当口，笔者在回顾这一年程序员世界的大事件后，突然发觉如何避免程序员面向监狱编程是个特别值得一谈的话题。
什么是内存泄漏
程序向系统申请内存，使用完不需要之后,不释放内存还给系统回收，造成申请的内存被浪费。
发现系统中内存使用量随着时间的流逝，消耗的越来越多，例如下图所示：
接下来的排查思路是：
1.监控系统中每个用户进程消耗的PSS (使用pmap工具(pmap pid))；
PSS:按比例报告的物理内存，比如进程A占用20M物理内存，进程B和进程A共享5M物理内存，那么进程A的PSS就是(20 - 5) + 5/2 = 17.5M；
2.监控/proc/meminfo输出,重点观察Slab使用量和slab对应的/proc/slabinfo信息；
3.参考/proc/meminfo输出，计算系统中未被统计的内存变化，比如内核驱动代码；
直接调用alloc_page()从buddy中拿走的内存不会被单独统计。
以上排查思路分别对应下图中的1,2,3 :
在排查的过程中发现系统非常空闲，都没有跑任何用户业务进程。
其中在使用slabtop监控slab的使用情况时发现size-4096 不停增长
通过监控/proc/slabinfo也发现SReclaimable 的使用量不停增长
while true;dosleep 1 ;cat /proc/slabinfo /tmp/slabinfo.txt ;echo "===" >> /tmp/slabinfo.txt ;done
由此判断很可能是内核空间在使用size-4096 时发生了内存泄漏。
trace-cmd record -e kmalloc-f 'bytes_alloc==4096' -e kfree -T
(-T 打印堆栈)
等待几分钟之后…
#ctrl ^c 中断trace-cmd
#trace-cmd report
以上步骤相当于：
等待几分钟之后…
#cp /sys/kernel/debug/tracing/trace_pipe /tmp/kmalloc-trace从trace-cmd report的输出结果来看，很多kmalloc 对应的ptr值都没有kfree与之对应的ptr值
这就说明了cat进程在内核空间使用size-4096之后并没有释放，造成了内存泄漏。
为了进一步精确定位到是使用哪个内核函数造成的问题，此时手动触发vmcore。
echo c > /proc/sysrq-trigger然后使用crash工具分析vmcore：
#crash ./vmcore ./vmlinux.debug读出上面kmalloc申请的ptr内存信息
(读取0xffff880423744000内存开始的4096个字节，并以字符形式显示)
发现从上面几个ptr内存中读出的内容都是非常相似，仔细看一下发现都是/proc/schedstat 的输出内容。
通过阅读相关代码发现，当读出/proc/schedstat内容之后，确实没有释放内存。
然后发现kernel上游已经有patch解决了这个问题：
commit: 8e0bcc722289
fix a leak in /proc/schedstats
在第 111 个女神节到来之际，CSDN 向所有技术女神致敬！并特邀产学研界的技术女神代表，共同探讨女性开发者的职业发展机遇与挑战，助力更多程序媛谱写精彩的程序人生。
以上是关于一次解决Linux内核内存泄漏实战全过程的主要内容，如果未能解决你的问题，请参考以下文章