原創:扣釘日記(微信公眾號ID:codelogs),歡迎分享,非公眾號轉載保留此宣告。
在之前的OOM問題覆盤中,我們新增了jmap指令碼來自動dump記憶體現場,方便排查OOM問題。
但當我反覆模擬OOM場景測試時,發現jmap有時可以dump成功,有時會報錯,如下:
經過網上一頓搜尋,發現兩種原因可能導致這個問題,一是執行jmap使用者與jvm程式使用者不一致,二是/tmp/.java_pidXXX
檔案被刪除,但經過檢查,這都不是我們jmap失敗的原因。
經過了解,jmap匯出記憶體的原理,大致如下:
- 如果jvm程式id是8255,jmap會先建立一個
/tmp/.java_pid8255
檔案,然後傳送SIGQUIT訊號給jvm。 - jvm收到訊號後啟動AttachListener執行緒,以UNIX domain socket的形式監聽
/tmp/.java_pid8255
檔案,以接收命令。 - jmap也以UNIX domain socket的形式連線上
/tmp/.java_pid8255
檔案,併傳送dumpheap命令給jvm,這個過程中jvm會檢查命令傳送方使用者的euid/egid是否與自己一致。 - AttachListener執行緒收到dumpheap命令後,等到JVM進入Safepoint後,執行HeapDumper操作以匯出heap.hprof檔案。
可以看出,當jvm已經卡死,或有長時間的GC正在Safepoint中執行,都會導致jmap長時間讀不到命令的響應而超時失敗!
使用jmap -F
當給jmap新增-F
引數時,jmap會使用Linux的ptrace
機制來匯出堆記憶體,ptrace
是Linux平臺的一種除錯機制,像strace、gdb都是基於它開發的,它使得除錯程式(jmap)可以直接讀取被除錯程式(jvm)的原生記憶體,然後jmap再根據jvm的記憶體佈局規範,將原生記憶體轉換為hprof格式。
但在實際執行時,會發現jmap -F
執行得非常慢,可能要幾個小時,這是因為ptrace
每次只能讀一個字的記憶體,而我們的堆有10G,因此jmap -F
對於我們幾乎無法使用。
注:這裡說的原生程式,指的是類似於C/C++這種直接編譯出來、不需要依賴語言虛擬機器的程式,而原生記憶體,指的是透過malloc或mmap等直接申請出來的記憶體。
使用gcore
有過Linux下原生程式除錯經驗的,應該會知道gcore這個實用工具,它可用來生成程式原生記憶體的core檔案,然後jstack、jmap等都可以讀取此類檔案,如下:
# 生成core檔案,8787是程式號
$ gcore -o core 8787
Saved corefile core.8787
[Inferior 1 (process 8787) detached]
$ ll -lh core.8787
-rw-r--r-- 1 work work 5.8G 2023-04-16 11:40:00 core.8787
# 從core檔案中讀取執行緒棧
$ jstack `which java` core.8787
# 將core檔案轉換為hprof檔案,很慢,建議摘流量後執行
$ jmap -dump:format=b,file=heap.hprof `which java` core.8787
但是當我使用jmap轉換core檔案時,我發現我本機測試時可以成功,但在測試伺服器上卻一直報錯,如下:
我網上找了好久,都沒找到報此錯誤的原因...
但我發現gcore執行時,是有一些警告資訊的,如下:
看起來可能是gcore匯出的core檔案不全,聯想到jvm部署在容器中,懷疑是有某些許可權限制,導致部分程式記憶體匯出失敗了。
使用Linux核心的coredump機制
除了gcore可以導原生記憶體,其實Linux核心也有自動的coredump機制,即程式在收到某些訊號後,會自動觸發核心的coredump機制,核心會負責將程式的原生記憶體儲存為core檔案,而核心一般是最高許可權執行的,所以它生成的core檔案應該是完整的。
先開啟coredump機制,如下:
# 檢查是否開啟,輸出unlimited表示core檔案不受限制,即完全開啟
$ ulimit -c
# 臨時開啟coredump
$ ulimit -c unlimited
# 永久開啟
$ echo "ulimit -c unlimited" >> /etc/profile
然後,配置一下coredump檔案儲存位置,如下:
# 檢視當前配置
$ cat /proc/sys/kernel/core_pattern
/home/core/core.%e.%p.%t
# 配置coredump檔案儲存位置,並使其生效
$ vi /etc/sysctl.conf
kernel.core_pattern=/home/core/core.%e.%p.%t
$ sysctl –p /etc/sysctl.conf
core_pattern佔位符解釋
佔位符 | 解釋 |
---|---|
%p | pid |
%u | uid |
%g | gid |
%s | signal number |
%t | UNIX time of dump |
%h | hostname |
%e | executable filename |
注:如果沒有許可權修改core_pattern路徑,可考慮使用軟連結
ln -s
做路徑跳轉,當然,還需要保證coredump路徑有寫入許可權。
配置ok後,可透過kill傳送訊號來觸發核心coredump,可觸發coredump的常見訊號如下:
- SIGQUIT 數值2 從鍵盤輸入
Ctrl+'\'
可以產生此訊號 - SIGILL 數值4 非法指令
- SIGABRT 數值6 abort呼叫
- SIGSEGV 數值11 非法記憶體訪問
- SIGTRAP 數值5 除錯程式時使用的斷點
我選擇了SIGABRT訊號,即kill -6
,經過驗證,可生成core檔案,而且core檔案也能被jmap轉換為hprof檔案。
有了hprof檔案,就可以愉快地使用MAT、JVisualVM、JMC等工具進行記憶體分析啦?