大家好,我是极客范的本期栏目编辑小友,现在为大家讲解Linux内核内存泄漏怎么办?问题。
什么是内存泄漏:
向系统申请内存,使用后不释放,将内存退回系统回收,造成申请内存的浪费。
发现随着时间的推移,系统中的内存使用越来越消耗,如下图所示:
接下来的故障排除思路是:
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()从好友处获取的内存不会单独计算。
以上故障排除思路对应下图中的1、2、3 :
在调查过程中,发现系统非常闲置,没有运行任何用户业务流程。
其中,在使用slabtop监控SLAB的使用情况时,发现size-4096不断增加。
通过monitoring /proc/slabinfo还发现,SReclaimable的使用量在不断增加。
虽然真实;做睡眠1;cat/proc/SLA binfo/tmp/SLA binfo . txt;echo '==='/tmp/slabinfo . txt;完成的
因此,当使用size-4096时,内核空间很可能存在内存泄漏。
接下来,使用trace event(tracepoint)函数监控size-4096的使用和发布过程。
主要用于跟踪kmalloc()和kfree()函数对应的traceevents,因为它们的traceevents被触发后,会打印kmalloc()和kfree()申请和释放的内存地址,然后只会进一步过滤掉4096字节的应用。
#trace-cmd记录-e kmalloc-f ' bytes _ alloc==4096 '-e kfree-T
(-t打印堆栈)
等几分钟.
# ctrl c中断跟踪-cmd
#trace-cmd报告
上述步骤相当于:
等几分钟.
# CP/sys/kernel/debug/trace/trace _ pipe/tmp/kmalloc-trace
根据trace-cmd报表的输出结果,很多kmalloc对应的ptr值没有kfree对应的ptr值。
这说明在内核空间使用size-4096后,cat进程还没有释放,导致内存泄漏。
为了进一步查明是哪个内核函数导致了问题,此时会手动触发vmcore。
# echo c/proc/sysrq-触发器
tyle="text-indent:2em;">然后使用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
原文标题:一次解决Linux内核内存泄漏实战全过程
文章出处:【微信公众号:Linuxer】欢迎添加关注!文章转载请注明出处。
责任编辑:haq
什么是内存泄漏:
程序向系统申请内存,使用完不需要之后,不释放内存还给系统回收,造成申请的内存被浪费.
发现系统中内存使用量随着时间的流逝,消耗的越来越多,例如下图所示:
接下来的排查思路是:
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; do sleep 1 ; cat /proc/slabinfo >> /tmp/slabinfo.txt ; echo"===">> /tmp/slabinfo.txt ; done
由此判断很可能是内核空间在使用size-4096 时发生了内存泄漏.
接下来使用trace event(tracepoint)功能来监控size-4096的使用和释放过程,
主要用来跟踪kmalloc()和kfree()函数对应的trace event, 因为他们的trace event被触发之后会打印kmalloc()和kfree()所申请和释放的内存地址,然后进一步只过滤申请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
原文标题:一次解决Linux内核内存泄漏实战全过程
文章出处:【微信公众号:Linuxer】欢迎添加关注!文章转载请注明出处。
责任编辑:haq
.dfma { position: relative; width: 1000px; margin: 0 auto; } .dfma a::after { position: absolute; left: 0; bottom: 0; width: 30px; line-height: 1.4; text-align: center; background-color: rgba(0, 0, 0, .5); color: #fff; font-size: 12px; content:"广告"; } .dfma img { display: block; }