一、 問題現(xiàn)象

客戶收到系統(tǒng)告警，K8S 集群某些節(jié)點 used 內存持續(xù)升高，top 查看進程使用的內存并不多，剩余內存不足卻找不到內存的使用者，內存神秘消失，需要排查內存去哪兒了。

執(zhí)行 top 指令并按內存排序輸出，內存使用最多的進程才 800M 左右，加起來遠達不到 used 9G 的使用量。

二、問題分析

2.1 內存去哪兒了？

在分析具體問題前，我們先把系統(tǒng)內存分類，便于找到內存使用異常的地方，從內存使用性質上，可以簡單把內存分為應用內存和內核內存，兩種內存使用量加上空閑內存，應該接近于 memory total，這樣區(qū)分能夠快速定位問題的邊界。

其中 allocpage 指通過 __get_free_pages/alloc_pages 等 API 接口直接從伙伴系統(tǒng)申請的內存量(不包含 slab 和 vmalloc)。

2.1.1 內存分析

根據(jù)內存大圖分別計算應用內存和內核內存，就可以知道是哪部分存在異常，但這些指標計算比較繁瑣，很多內存值還存在重疊。針對這個痛點，SysOM 運維平臺的內存大盤功能以可視化的方式展示內存的使用情況，并直接給出內存是否存在泄漏，本案例中，使用 SysOM 檢測，直接顯示 allocpage 存在泄漏，使用量接近 6G。

2.1.2 allocpage 內存

那既然是 alloc page 類型的內存占用多，是否可以直接從 sysfs、procfs 文件節(jié)點查看其內存使用了？很遺憾，這部分內存是內核/驅動直接調用 __get_free_page/alloc_pages 等函數(shù)從伙伴系統(tǒng)申請單個或多個連續(xù)的頁面，系統(tǒng)層面沒有接口查詢這部分內存使用詳情。如果這類內存存在泄漏，就會出現(xiàn)"內存憑空消失"的現(xiàn)象，比較難發(fā)現(xiàn)，問題原因也難排查。針對這個難點，我們的SysOM系統(tǒng)運維能夠覆蓋這類內存統(tǒng)計和原因診斷。

所以需要進一步通過SysOM的診斷利器 SysAK 動態(tài)抓取這類內存的使用情況。

2.2 allocPage 類型內存排查

2.2.1 動態(tài)診斷

對于內核內存泄漏，我們直接可以使用SysAK工具來動態(tài)追蹤，啟動命令并等待 10 分鐘。

sysak memleak -t page -i 600

診斷結果顯示 10 分鐘內 receive_mergeable 函數(shù)分配的內存有 4919 次沒有釋放，內存大小在 300M 左右，分析到這里，我們就需要結合代碼來確認 receive_mergeable 函數(shù)的內存分配和釋放邏輯是否正確。

2.2.2 分配和釋放總結

1）page_to_skb 每次會分配一個線性數(shù)據(jù)區(qū)為 128 Byte 的 skb。

2）數(shù)據(jù)區(qū)調用 alloc_pages_node 函數(shù)，一次性從伙伴系統(tǒng)申請 32k 內存(order=3)。

3）每個 skb 會對 32k 的 head page 產(chǎn)生一次引用計數(shù)，也就是只有當所有 skb 都釋放時，這 32k 內存才釋放回伙伴系統(tǒng)。

4）receive_mergeable 函數(shù)負責申請內存，但不負責釋放這部分內存，只有當應用從 socket recvQ 中把數(shù)據(jù)讀走才會對 head page 引用計數(shù)減一，當 page refs 為 0 時，釋放回伙伴系統(tǒng)。

當應用消費數(shù)據(jù)比較慢，可能會導致 receive_mergeable 函數(shù)申請的內存釋放不及時，而且最壞情況一個 skb 會占用 32k 內存，使用 sysak skcheck 檢查 socket 接收隊列和發(fā)送隊列殘留情況。

從輸出可以知道，系統(tǒng)中只有 nginx 進程的接收隊列有殘留數(shù)據(jù)，socket fd=11 的 Recv-Q 有接近 3M 的數(shù)據(jù)沒有接收，通過直接 kill 146935，系統(tǒng)內存恢復正常了，所以問題根本原因就是 nginx 沒有及時收走數(shù)據(jù)了。

三、問題結論

經(jīng)過與業(yè)務方溝通，最終確認是業(yè)務配置問題，導致 nginx 有一個線程沒有處理數(shù)據(jù)，從而導致網(wǎng)卡驅動申請的內存沒有及時釋放，而 allocpage 內存又是無法統(tǒng)計的，從而出現(xiàn)內存憑空消失的現(xiàn)象。

3.1 結論驗證

接收隊列真的有數(shù)據(jù)殘留嗎，這里結合 crash 工具的 files 指令通過 fd 找到對應的sock：

通過多次觀察，發(fā)現(xiàn) sk_receive_queue 上的 skb 長時間沒有變化，這也證明了 nginx 沒有及時處理接收隊列上的 skb，導致在網(wǎng)卡驅動中分配的內存沒有釋放。

四、內存泄漏疑點

在排查過程還遇到一個非常較困惑的地方，sockstat 和 slabtop 看檢查 tcp mem 和 skbuff_head_cache 使用都很正常，導致進一步掩蓋了網(wǎng)絡占用的內存。

tcp mem = 32204*4K=125M

skb 數(shù)量在 1.5萬~3 萬之間。

按照前面分析，一個skb最壞情況占用 32k 內存，那么 2 萬個 skb 最大也就占 600M 左右，怎么會占用幾個 G 了，難道分析有問題？如下圖所示，skb 的非線性區(qū)可能還存在若干個 frag page，而每個 frag page 又可能由 compund page 組成。

用 crash 實際讀取 skb 內存發(fā)現(xiàn)，有些 skb 存在 17 個 frag page，并且數(shù)據(jù)大小只有 10 Byte。

解析 frag page 的 order 為 3，意味著一個 frag page 占用 32k 內存。

極端情況下，一個 skb 可能占用(1+17)*8=144 頁，上圖 slabinfo 中skbuff_head_cache 活躍 object 數(shù)量為 15033 個，所以理論最大總內存 =144*15033*4K = 8.2G，而我們現(xiàn)在遇到的場景消耗 6G 的內存是完全有可能的。



審核編輯：劉清