一次解決Linux內核內存泄漏實戰(zhàn)全過程
什么是內存泄漏：
程序向系統(tǒng)申請內存，使用完不需要之后,不釋放內存還給系統(tǒng)回收，造成申請的內存被浪費.
發(fā)現(xiàn)系統(tǒng)中內存使用量隨著時間的流逝，消耗的越來越多，例如下圖所示：
接下來的排查思路是:
1.監(jiān)控系統(tǒng)中每個用戶進程消耗的PSS (使用pmap工具(pmap pid)).
PSS:按比例報告的物理內存，比如進程A占用20M物理內存，進程B和進程A共享5M物理內存，那么進程A的PSS就是(20 - 5) + 5/2 = 17.5M
2.監(jiān)控/proc/meminfo輸出,重點觀察Slab使用量和slab對應的/proc/slabinfo信息
3.參考/proc/meminfo輸出，計算系統(tǒng)中未被統(tǒng)計的內存變化，比如內核驅動代碼
直接調用alloc_page()從buddy中拿走的內存不會被單獨統(tǒng)計
以上排查思路分別對應下圖中的1,2,3 :
在排查的過程中發(fā)現(xiàn)系統(tǒng)非常空閑，都沒有跑任何用戶業(yè)務進程。
其中在使用slabtop監(jiān)控slab的使用情況時發(fā)現(xiàn)size-4096 不停增長
通過監(jiān)控/proc/slabinfo也發(fā)現(xiàn)SReclaimable 的使用量不停增長
- while true;
- do
- sleep 1 ;
- cat /proc/slabinfo >> /tmp/slabinfo.txt ;
- echo "===" >> /tmp/slabinfo.txt ;
- done
由此判斷很可能是內核空間在使用size-4096 時發(fā)生了內存泄漏.
接下來使用trace event(tracepoint)功能來監(jiān)控size-4096的使用和釋放過程，
主要用來跟蹤kmalloc()和kfree()函數(shù)對應的trace event, 因為他們的trace event被觸發(fā)之后會打印kmalloc()和kfree()所申請和釋放的內存地址,然后進一步只過濾申請4096字節(jié)的情況。
- #trace-cmd record -e kmalloc
- -f 'bytes_alloc==4096' -e kfree -T
(-T 打印堆棧)
等待幾分鐘之后…
- #cp /sys/kernel/debug/tracing/trace_pipe /tmp/kmalloc-trace
#trace-cmd report
以上步驟相當于：
等待幾分鐘之后…
- #cp /sys/kernel/debug/tracing/trace_pipe /tmp/kmalloc-trace
從trace-cmd report的輸出結果來看，很多kmalloc 對應的ptr值都沒有kfree與之對應的ptr值
這就說明了cat進程在內核空間使用size-4096之后并沒有釋放，造成了內存泄漏。
為了進一步精確定位到是使用哪個內核函數(shù)造成的問題，此時手動觸發(fā)vmcore
- #echo c > /proc/sysrq-trigger
然后使用crash工具分析vmcore：
- #crash ./vmcore ./vmlinux.debug
讀出上面kmalloc申請的ptr內存信息
(讀取0xffff880423744000內存開始的4096個字節(jié)，并以字符形式顯示)
發(fā)現(xiàn)從上面幾個ptr內存中讀出的內容都是非常相似，仔細看一下發(fā)現(xiàn)都是/proc/schedstat 的輸出內容。
通過閱讀相關代碼發(fā)現(xiàn)，當讀出/proc/schedstat內容之后，確實沒有釋放內存
然后發(fā)現(xiàn)kernel上游已經(jīng)有patch解決了這個問題：
commit: 8e0bcc722289
fix a leak in /proc/schedstats
本文轉載自微信公眾號「Linux閱碼場」，可以通過以下二維碼關注。轉載本文請聯(lián)系Linux閱碼場公眾號。
