使用 NMT 和 pmap 解決 JVM 資源洩漏問題
編者按:筆者使用 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>
NMT 引數的含義可以通過 "jcmd <pid>
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
上圖只是截取了 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源創計劃”,歡迎正在閱讀的你也加入,一起分享。
- 玩轉機密計算從 secGear 開始
- openEuler資源利用率提升之道06:虛擬機器混部OpenStack排程
- openGauss Cluster Manager RTO Test
- JVM 鎖 bug 導致 G1 GC 掛起問題分析和解決【畢昇JDK技術剖析 · 第 2 期】
- 手把手帶你玩轉 openEuler | openEuler 的使用
- 681名學生中選!暑期2021開啟火熱“開源之夏”!
- 手把手帶你玩轉 openEuler | 初識 openEuler
- StratoVirt 中的 PCI 裝置熱插拔實現
- 使用 NMT 和 pmap 解決 JVM 資源洩漏問題
- JNI 中錯誤的訊號處理導致 JVM 崩潰問題分析
- Java Flight Recorder - 事件機制詳解
- 畢昇 JDK 8u292、11.0.11 釋出!
- StratoVirt 中的虛擬網絡卡是如何實現的?
- openEuler結合ebpf提升ServiceMesh服務體驗的探索
- 我的openEuler社群參與之旅
- StratoVirt 的中斷處理是如何實現的?
- 看看畢昇 JDK 團隊是如何解決 JVM 中 CMS 的 Crash
- 使用 perf 解決 JDK8 小版本升級後效能下降的問題【畢昇JDK技術剖析 · 第 1 期】
- 2021年畢昇 JDK 的第一個重要更新來了
- 漏洞盒子 × openEuler | 廣邀白帽共築安全的Linux開放應用生態