共計 1673 個字符，預計需要花費 5 分鐘才能閱讀完成。

這篇文章主要講解了“怎么解決 Linux 內核內存泄漏”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“怎么解決 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() 從 buddy 中拿走的內存不會被單獨統計

以上排查思路分別對應下圖中的 1,2,3 :

在排查的過程中發現系統非?？臻e，都沒有跑任何用戶業務進程。

其中在使用 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 打印堆棧)

等待幾分鐘之后 hellip;

#cp /sys/kernel/debug/tracing/trace_pipe /tmp/kmalloc-trace

#trace-cmd report

以上步驟相當于：

等待幾分鐘之后 hellip;

#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 內核內存泄漏”的內容了，經過本文的學習后，相信大家對怎么解決 Linux 內核內存泄漏這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！