|
2020 年轉(zhuǎn)眼間白駒過隙般飛奔而去，在歲末年初的當(dāng)口，筆者在回顧這一年程序員世界的大事件后，突然發(fā)覺如何避免程序員面向監(jiān)獄編程是個特別值得一談的話題。 什么是內(nèi)存泄漏 程序向系統(tǒng)申請內(nèi)存，使用完不需要之后,不釋放內(nèi)存還給系統(tǒng)回收，造成申請的內(nèi)存被浪費(fèi)。 發(fā)現(xiàn)系統(tǒng)中內(nèi)存使用量隨著時間的流逝，消耗的越來越多，例如下圖所示： 接下來的排查思路是： 1.監(jiān)控系統(tǒng)中每個用戶進(jìn)程消耗的PSS (使用pmap工具(pmap pid))； PSS:按比例報告的物理內(nèi)存，比如進(jìn)程A占用20M物理內(nèi)存，進(jìn)程B和進(jìn)程A共享5M物理內(nèi)存，那么進(jìn)程A的PSS就是(20 - 5) 5/2 = 17.5M； 2.監(jiān)控/proc/meminfo輸出,重點觀察Slab使用量和slab對應(yīng)的/proc/slabinfo信息； 3.參考/proc/meminfo輸出，計算系統(tǒng)中未被統(tǒng)計的內(nèi)存變化，比如內(nèi)核驅(qū)動代碼； 直接調(diào)用alloc_page()從buddy中拿走的內(nèi)存不會被單獨(dú)統(tǒng)計。 以上排查思路分別對應(yīng)下圖中的1,2,3 : 在排查的過程中發(fā)現(xiàn)系統(tǒng)非?？臻e，都沒有跑任何用戶業(yè)務(wù)進(jìn)程。 其中在使用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由此判斷很可能是內(nèi)核空間在使用size-4096 時發(fā)生了內(nèi)存泄漏。 接下來使用trace event(tracepoint)功能來監(jiān)控size-4096的使用和釋放過程，主要用來跟蹤kmalloc()和kfree()函數(shù)對應(yīng)的trace event, 因為他們的trace event被觸發(fā)之后會打印kmalloc()和kfree()所申請和釋放的內(nèi)存地址,然后進(jìn)一步只過濾申請4096字節(jié)的情況。 #trace-cmd record -e kmalloc -f 'bytes_alloc==4096' -e kfree -T (-T 打印堆棧) 等待幾分鐘之后… #ctrl ^c 中斷trace-cmd #trace-cmd report 以上步驟相當(dāng)于： 等待幾分鐘之后… #cp /sys/kernel/debug/tracing/trace_pipe /tmp/kmalloc-trace從trace-cmd report的輸出結(jié)果來看，很多kmalloc 對應(yīng)的ptr值都沒有kfree與之對應(yīng)的ptr值 這就說明了cat進(jìn)程在內(nèi)核空間使用size-4096之后并沒有釋放，造成了內(nèi)存泄漏。 為了進(jìn)一步精確定位到是使用哪個內(nèi)核函數(shù)造成的問題，此時手動觸發(fā)vmcore。 #echo c > /proc/sysrq-trigger 然后使用crash工具分析vmcore： #crash ./vmcore ./vmlinux.debug讀出上面kmalloc申請的ptr內(nèi)存信息 (讀取0xffff880423744000內(nèi)存開始的4096個字節(jié)，并以字符形式顯示) 發(fā)現(xiàn)從上面幾個ptr內(nèi)存中讀出的內(nèi)容都是非常相似，仔細(xì)看一下發(fā)現(xiàn)都是/proc/schedstat 的輸出內(nèi)容。 通過閱讀相關(guān)代碼發(fā)現(xiàn)，當(dāng)讀出/proc/schedstat內(nèi)容之后，確實沒有釋放內(nèi)存。 然后發(fā)現(xiàn)kernel上游已經(jīng)有patch解決了這個問題： commit: 8e0bcc722289 fix a leak in /proc/schedstats |
|
|
