Java服務(wù),內(nèi)存OOM問題如何快速定位?
最近有朋友在知識星球提問:
沈老師,有一個Java服務(wù)出現(xiàn)了OOM(Out Of Memory)問題,定位了好久不得其法,請問有什么好的思路么?
OOM的問題,印象中之前寫過,這里再總結(jié)一些相對通用的方案,希望能幫助到Java技術(shù)棧的同學。
某Java服務(wù)(假設(shè)PID=10765)出現(xiàn)了OOM,最常見的原因為:
- 有可能是內(nèi)存分配確實過小,而正常業(yè)務(wù)使用了大量內(nèi)存
- 某一個對象被頻繁申請,卻沒有釋放,內(nèi)存不斷泄漏,導(dǎo)致內(nèi)存耗盡
- 某一個資源被頻繁申請,系統(tǒng)資源耗盡,例如:不斷創(chuàng)建線程,不斷發(fā)起網(wǎng)絡(luò)連接
畫外音:無非“本身資源不夠”“申請資源太多”“資源耗盡”幾個原因。
更具體的,可以使用以下工具逐一排查。
一、確認是不是內(nèi)存本身就分配過小
方法:
- jmap -heap 10765
如上圖,可以查看新生代,老生代堆內(nèi)存的分配大小以及使用情況,看是否本身分配過小。
二、找到最耗內(nèi)存的對象
方法:
- jmap -histo:live 10765 | more
如上圖,輸入命令后,會以表格的形式顯示存活對象的信息,并按照所占內(nèi)存大小排序:
- 實例數(shù)
- 所占內(nèi)存大小
- 類名
是不是很直觀?對于實例數(shù)較多,占用內(nèi)存大小較多的實例/類,相關(guān)的代碼就要針對性review了。
上圖中占內(nèi)存最多的對象是RingBufferLogEvent,共占用內(nèi)存18M,屬于正常使用范圍。
如果發(fā)現(xiàn)某類對象占用內(nèi)存很大(例如幾個G),很可能是類對象創(chuàng)建太多,且一直未釋放。例如:
- 申請完資源后,未調(diào)用close()或dispose()釋放資源
- 消費者消費速度慢(或停止消費了),而生產(chǎn)者不斷往隊列中投遞任務(wù),導(dǎo)致隊列中任務(wù)累積過多
畫外音:線上執(zhí)行該命令會強制執(zhí)行一次fgc。另外還可以dump內(nèi)存進行分析。
三、確認是否是資源耗盡
工具:
- pstree
- netstat
查看進程創(chuàng)建的線程數(shù),以及網(wǎng)絡(luò)連接數(shù),如果資源耗盡,也可能出現(xiàn)OOM。 這里介紹另一種方法,通過
- /proc/${PID}/fd
- /proc/${PID}/task
可以分別查看句柄詳情和線程數(shù)。 例如,某一臺線上服務(wù)器的sshd進程PID是9339,查看
- ll /proc/9339/fd
- ll /proc/9339/task
如上圖,sshd共占用了四個句柄:
- 0 -> 標準輸入
- 1 -> 標準輸出
- 2 -> 標準錯誤輸出
- 3 -> socket(容易想到是監(jiān)聽端口)
sshd只有一個主線程PID為9339,并沒有多線程。
所以,只要
- ll /proc/${PID}/fd | wc -l
- ll /proc/${PID}/task | wc -l (效果等同pstree -p | wc -l)
就能知道進程打開的句柄數(shù)和線程數(shù)。
希望這1分鐘能幫到這位星球水友。
【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件,轉(zhuǎn)載請聯(lián)系原作者】