使用 NMT 和 pmap 解決 JVM 資源泄漏問題

語言: CN / TW / HK

編者按:筆者使用 JDK 自帶的內存跟蹤工具 NMT 和 Linux 自帶的 pmap 解決了一個非常典型的資源泄漏問題。這個資源泄漏是由於 Java 程序員不正確地使用 Java API 導致的,使用 Files.list 打開的文件描述符必須關閉。本案例一方面介紹了怎麼使用 NMT 解決 JVM 資源泄漏問題,如果讀者遇到類似問題,可以嘗試用 NMT 來解決;另一方面也提醒 Java 開發人員使用 Java API 時需要必須弄清楚 API 使用規範,希望大家通過這個案例有所收穫。

背景知識:

NMT

NMT 是 Native Memory Tracking 的縮寫,一個 JDK 自帶的小工具,用來跟蹤 JVM 本地內存分配情況(本地內存指的是 non-heap,例如 JVM 在運行時需要分配一些輔助數據結構用於自身的運行)。

NMT 功能默認關閉,可以在 Java 程序啟動參數中加入以下參數來開啟:

-XX:NativeMemoryTracking=[summary | detail]

其中,"summary" 和 "detail" 的差別主要在輸出信息的詳細程度。

開啟 NMT 功能後,就可以使用 JDK 提供的 jcmd 命令來讀取 NMT 採集的數據了,具體命令如下:

jcmd <pid>  VM.native_memory [summary | detail | baseline | summary.diff | detail.diff | shutdown]

NMT 參數的含義可以通過 "jcmd <pid>  help VM.native_memory" 命令查詢。通過 NMT 工具,我們可以快速區分內存泄露是否源自 JVM 分配。

pmap

對於非 JVM 分配的內存,經常需要用到 pmap 這個工具了,這是一個 linux 系統自帶工具,能夠從系統層面輸出目標進程內存使用的詳細情況,用法非常簡單:

pmap [參數] <pid>

常用的選項是 "-x" 或 "-X",都是用來控制輸出信息的詳細程度。

上圖是 pmap 部分輸出信息,每列含義為

Address 每段內存空間起始地址
Kbytes 每段內存空間大小(單位 KB)
RSS 每段內存空間實際使用內存大小(單位 KB)
Dirty 每段內存空間髒頁大小(單位 KB)
Mode 每段內存空間權限屬性
Mapping 可以映射到文件,也可以是“anon”表示匿名內存段,還有一些特殊名字如“stack”

現象:

某業務集羣中,多個節點出現業務進程內存消耗緩慢增長現象,以其中一個節點為例:

如圖所示,這個業務進程當前佔用了 4.7G 的虛擬內存空間,以及 2.2G 的物理內存。已知正常狀態下該業務進程的物理內存佔用量不超過 1G。

分析:

使用命令 "jcmd VM.native_memory detail" 可以看到所有受 JVM 監控的內存分佈情況:

上圖只是截取了 nmt(Native Memory Tracking) 命令展示的概覽信息,這個業務進程佔用的 2.2G 物理內存中,受 JVM 監控的大概只佔了 0.7G(上圖中的 committed),意味着有 1.5G 物理內存不受 JVM 管控。JVM 可以監控到 Java 堆、元空間、CodeCache、直接內存等區域,但無法監控到那些由 JVM 之外的 Native Code 申請的內存,例如典型的場景:第三方 so 庫中調用 malloc 函數申請一塊內存的行為無法被 JVM 感知到。

nmt 除了會展示概覽之外,還會詳細羅列每一片受 JVM 監控的內存,包括其地址,將這些 JVM 監控到的內存佈局和用 pmap 得到的完整的進程內存佈局做一個對比篩查,這裏忽略 nmt 和 pmap(下圖 pmap 命令中 25600 是進程號)詳細內存地址的信息,直接給出最可疑的那塊內存:

由圖可知,這片 1.7G 左右的內存區域屬於系統層面的堆區。

備註:這片系統堆區之所以稍大於上面計算得到的差值,原因大概是 nmt 中顯示的 committed 內存並不對應真正佔用的物理內存(linux 使用 Lazy 策略管理進程內存),實際通常會稍小。

系統堆區主要就是由 libc 庫接口 malloc 申請的內存組合而成,所以接下來就是去跟蹤業務進程中的每次 malloc 調用,可以藉助 GDB:

實際上會有大量的干擾項,這些干擾項一方面來自 JVM 內部,比如:

這部分干擾項很容易被排除,凡是調用棧中存在 "os::malloc" 這個棧幀的干擾項就可以直接忽視,因為這些 malloc 行為都會被 nmt 監控到,而上面已經排除了受 JVM 監控內存泄漏的可能。

另一部分干擾項則來自 JDK,比如:

有如上圖所示,不少 JDK 的本地方法中直接或間接調用了 malloc,這部分 malloc 行為通常是不受 JVM 監控的,所以需要根據具體情況逐個排查,還是以上圖為例,排查過程如下:

注意圖中臨時中斷的值(0x0000ffff5fc55d00)來自於第一個中斷 b malloc 中斷髮生後的結果。

這裏稍微解釋一下上面 GDB 在做的排查過程,就是檢查 malloc 返回的內存地址後續是否有通過 free 釋放(通過 tb free if X3 這個命令,具體用法可以參考 GDB 調試),顯然在這個例子中是有釋放的。

通過這種排查方式,幾經篩選,最終找到了一個可疑的 malloc 場景:

從調用棧信息可以知道,這是一個 JDK 中的本地方法 sun.nio.fs.UnixNativeDispatcher.opendir0,作用是打開一個目錄,但後續始終沒有進行關閉操作。進一步分析可知,該可疑 opendir 操作會週期性執行,而且都是操作同一個目錄 "/xxx/nginx/etc/nginx/conf",看來,是有個業務線程在定時訪問 nginx 的配置目錄,每次訪問完卻沒有關閉打開的目錄。

分析到這裏,其實這個問題已經差不多水落石出。和業務方確認,存在一個定時器線程在週期性讀取 nginx 的配置文件,代碼大概是這樣子的:

翻了一下相關 JDK 源碼,Files.list 方法是有在末尾註冊一個關閉鈎子的:

也就是説,Files.list 方法返回的目錄資源是需要手動釋放的,否則就會發生資源泄漏。

由於這個目錄資源底層是會關聯一個 fd 的,所以泄漏問題還可以通過另一個地方進行佐證:

該業務進程目前已經消耗了 51116 個 fd!

假設這些 fd 都是 opendir 關聯的,每個 opendir 消耗 32K,則總共消耗 1.6G,顯然可以跟上面泄漏的內存值基本對上。

總結:

稍微瞭解了一下,發現幾乎沒人知道 JDK 方法 Files.list 是需要關閉的,這個案例算是給大家都提了個醒。

後記:

如果遇到相關技術問題(包括不限於畢昇 JDK),可以進入畢昇 JDK 社區查找相關資源(點擊閲讀原文進入官網),包括二進制下載、代碼倉庫、使用教學、安裝、學習資料等。畢昇 JDK 社區每雙週週二舉行技術例會,同時有一個技術交流羣討論 GCC、LLVM、JDK 和 V8 等相關編譯技術,感興趣的同學可以添加如下微信小助手,回覆 Compiler 入羣。


本文分享自微信公眾號 - openEuler(openEulercommunity)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閲讀的你也加入,一起分享。