快捷導(dǎo)航

jmap執(zhí)行失敗如何獲取heapdump詳解

更新時(shí)間：2023年04月16日 15:58:31 作者：扣釘日記

這篇文章主要為大家介紹了jmap執(zhí)行失敗如何獲取heapdump詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪

正文

在之前的OOM問(wèn)題復(fù)盤(pán)中，我們添加了jmap腳本來(lái)自動(dòng)dump內(nèi)存現(xiàn)場(chǎng)，方便排查OOM問(wèn)題。

但當(dāng)我反復(fù)模擬OOM場(chǎng)景測(cè)試時(shí)，發(fā)現(xiàn)jmap有時(shí)可以dump成功，有時(shí)會(huì)報(bào)錯(cuò)，如下：

經(jīng)過(guò)網(wǎng)上一頓搜索，發(fā)現(xiàn)兩種原因可能導(dǎo)致這個(gè)問(wèn)題，一是執(zhí)行jmap用戶(hù)與jvm進(jìn)程用戶(hù)不一致，二是/tmp/.java_pidXXX文件被刪除，但經(jīng)過(guò)檢查，這都不是我們jmap失敗的原因。

經(jīng)過(guò)了解，jmap導(dǎo)出內(nèi)存的原理，大致如下：

如果jvm進(jìn)程id是8255，jmap會(huì)先創(chuàng)建一個(gè)/tmp/.java_pid8255文件，然后發(fā)送SIGQUIT信號(hào)給jvm。
jvm收到信號(hào)后啟動(dòng)AttachListener線(xiàn)程，以UNIX domain socket的形式監(jiān)聽(tīng)/tmp/.java_pid8255文件，以接收命令。
jmap也以UNIX domain socket的形式連接上/tmp/.java_pid8255文件，并發(fā)送dumpheap命令給jvm，這個(gè)過(guò)程中jvm會(huì)檢查命令發(fā)送方用戶(hù)的euid/egid是否與自己一致。
AttachListener線(xiàn)程收到dumpheap命令后，等到JVM進(jìn)入Safepoint后，執(zhí)行HeapDumper操作以導(dǎo)出heap.hprof文件。

可以看出，當(dāng)jvm已經(jīng)卡死，或有長(zhǎng)時(shí)間的GC正在Safepoint中執(zhí)行，都會(huì)導(dǎo)致jmap長(zhǎng)時(shí)間讀不到命令的響應(yīng)而超時(shí)失?。?/p>

使用jmap -F

當(dāng)給jmap添加-F參數(shù)時(shí)，jmap會(huì)使用Linux的ptrace機(jī)制來(lái)導(dǎo)出堆內(nèi)存，ptrace是Linux平臺(tái)的一種調(diào)試機(jī)制，像strace、gdb都是基于它開(kāi)發(fā)的，它使得調(diào)試進(jìn)程(jmap)可以直接讀取被調(diào)試進(jìn)程(jvm)的原生內(nèi)存，然后jmap再根據(jù)jvm的內(nèi)存布局規(guī)范，將原生內(nèi)存轉(zhuǎn)換為hprof格式。

但在實(shí)際執(zhí)行時(shí)，會(huì)發(fā)現(xiàn)jmap -F執(zhí)行得非常慢，可能要幾個(gè)小時(shí)，這是因?yàn)?code>ptrace每次只能讀一個(gè)字的內(nèi)存，而我們的堆有10G，因此jmap -F對(duì)于我們幾乎無(wú)法使用。

注：這里說(shuō)的原生程序，指的是類(lèi)似于C/C++這種直接編譯出來(lái)、不需要依賴(lài)語(yǔ)言虛擬機(jī)的程序，而原生內(nèi)存，指的是通過(guò)malloc或mmap等直接申請(qǐng)出來(lái)的內(nèi)存。

使用gcore

有過(guò)Linux下原生程序調(diào)試經(jīng)驗(yàn)的，應(yīng)該會(huì)知道gcore這個(gè)實(shí)用工具，它可用來(lái)生成程序原生內(nèi)存的core文件，然后jstack、jmap等都可以讀取此類(lèi)文件，如下：

# 生成core文件，8787是進(jìn)程號(hào)
$ 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文件中讀取線(xiàn)程棧
$ jstack `which java` core.8787
# 將core文件轉(zhuǎn)換為hprof文件，很慢，建議摘流量后執(zhí)行
$ jmap -dump:format=b,file=heap.hprof `which java` core.8787

但是當(dāng)我使用jmap轉(zhuǎn)換core文件時(shí)，我發(fā)現(xiàn)我本機(jī)測(cè)試時(shí)可以成功，但在測(cè)試服務(wù)器上卻一直報(bào)錯(cuò)，如下：

我網(wǎng)上找了好久，都沒(méi)找到報(bào)此錯(cuò)誤的原因...

但我發(fā)現(xiàn)gcore執(zhí)行時(shí)，是有一些警告信息的，如下：

看起來(lái)可能是gcore導(dǎo)出的core文件不全，聯(lián)想到j(luò)vm部署在容器中，懷疑是有某些權(quán)限限制，導(dǎo)致部分程序內(nèi)存導(dǎo)出失敗了。

使用Linux內(nèi)核的coredump機(jī)制

除了gcore可以導(dǎo)原生內(nèi)存，其實(shí)Linux內(nèi)核也有自動(dòng)的coredump機(jī)制，即進(jìn)程在收到某些信號(hào)后，會(huì)自動(dòng)觸發(fā)內(nèi)核的coredump機(jī)制，內(nèi)核會(huì)負(fù)責(zé)將進(jìn)程的原生內(nèi)存保存為core文件，而內(nèi)核一般是最高權(quán)限運(yùn)行的，所以它生成的core文件應(yīng)該是完整的。

先開(kāi)啟coredump機(jī)制，如下：

# 檢查是否開(kāi)啟，輸出unlimited表示core文件不受限制，即完全開(kāi)啟
$ ulimit -c
# 臨時(shí)開(kāi)啟coredump
$ ulimit -c unlimited
# 永久開(kāi)啟
$ echo "ulimit -c unlimited" &gt;&gt; /etc/profile

然后，配置一下coredump文件保存位置，如下：

# 查看當(dāng)前配置
$ 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占位符解釋