什麼是記憶體洩漏：
程式向系統申請記憶體，使用完不需要之後,不釋放記憶體還給系統回收，造成申請的記憶體被浪費.
發現系統中記憶體使用量随着時間的流逝，消耗的越來越多，例如下圖所示：
接下來的排查思路是:
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 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