這篇文章將為大家詳細講解有關(guān)生產(chǎn)環(huán)境JVM內(nèi)存溢出的示分析,文章內(nèi)容質(zhì)量較高,因此小編分享給大家做個參考,希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。
專注于為中小企業(yè)提供網(wǎng)站制作、成都網(wǎng)站制作服務(wù),電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)巴彥免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都,凝聚了一批互聯(lián)網(wǎng)行業(yè)人才,有力地推動了近千家企業(yè)的穩(wěn)健成長,幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。
如果我們所在公司的業(yè)務(wù)量比較大,在生產(chǎn)環(huán)境經(jīng)常會出現(xiàn)JVM內(nèi)存溢出的現(xiàn)象,那我們該如何快速響應(yīng),快速定位,快速恢復(fù)問題呢?
通過一個線上環(huán)境JVM內(nèi)存溢出的案例向大家介紹一下處理思路與分析方法。
案例:架構(gòu)組接到某項目組反饋,Zabbix監(jiān)控上顯示JMX不可用,請求協(xié)助處理。
分析思路:
JMX不可用,往往是由于垃圾回收時間停頓時間過長、內(nèi)存溢出等問題引起的。
線上故障分析的原則是首先要采取措施快速恢復(fù)故障對業(yè)務(wù)的影響,然后才是采集信息、分析定位問題,并最終給出解決辦法。
具體分析過程如下。
通常線上的故障會對業(yè)務(wù)造成重大影響,影響用戶體驗,故如果線上服務(wù)器出現(xiàn)故障,應(yīng)規(guī)避對業(yè)務(wù)造成影響,但不能簡單的重啟服務(wù)器,因為需要盡可能保留現(xiàn)場,為后續(xù)的問題分析打下基礎(chǔ)。
那我們?nèi)绾慰焖僖?guī)避對業(yè)務(wù)的影響,并能保留現(xiàn)場呢?
通常的做法是隔離故障服務(wù)器。
通常線上服務(wù)器是集群部署,一個好的分布式負載方案會自動剔除故障的機器,從而實現(xiàn)高可用架構(gòu),但如果未被剔除,則需要運維人員將故障服務(wù)器進行剔除,保留現(xiàn)場進行分析。
發(fā)生內(nèi)存泄露,通常情況下是由于代碼的原因造成的,一般無法立即對代碼進行修復(fù),很容易會發(fā)送連鎖反應(yīng)造成應(yīng)用服務(wù)器一臺一臺接連宕機,故障面積會慢慢擴大,針對此種情況,應(yīng)快速定位發(fā)生內(nèi)存泄露的原因,將該服務(wù)進行降級,避免對其他服務(wù)造成影響。最簡單的降級方法是根據(jù)F5(Nginx)轉(zhuǎn)發(fā)策略,對該功能定向到一個單獨的集群,與其他流量進行隔離,確保其他業(yè)務(wù)不受牽連,給故障排查、解決提供寶貴的緩沖時間。
首先可以通過查看日志,確定是哪種內(nèi)存溢出,堆內(nèi)存溢出可發(fā)生的地方:Java heap space(堆空間)、perm space(持久代)。
收集Dump文件有兩種方式:
設(shè)置JVM啟動參數(shù)
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/opt/jvmdump
在每次發(fā)生內(nèi)存溢出時,JVM會自動將堆轉(zhuǎn)儲,dump文件存放在-XX:HeapDumpPath指定的路徑下。
使用jmap命令收集
通過jmap -dump:live,format=b,file=/opt/jvm/dump.hprof pid。
在獲取Dump文件后,可以使用工具MAT(MemoryAnalyzer)進行分析,該工具大家可以通過百度自行下載。
使用MAT打開Dump文件后,首頁截圖如下:
工具按鈕介紹:
:直方圖視圖,將堆中所有的內(nèi)存消耗情況統(tǒng)計出來,其如圖所示:
:內(nèi)存使用樹狀結(jié)構(gòu),以線程為維度,樹狀形式展開,如圖所示:
線程棧,其截圖如下:
根據(jù)該圖,可以明確,堆的總大小為1.9G,被4個線程全部占據(jù),導(dǎo)致其他線程無法再申請資源,拋出堆內(nèi)存溢出錯誤。
接下來,我通常的做法是直接去看這個視圖(以線程為基本維度,查找線程中占用內(nèi)存的對象),為后續(xù)定位排查提供必要的依據(jù)。
從上面的截圖中可以得出如下關(guān)鍵信息點:
org.apache.ibatis.executor.result.DefaultResultHandler內(nèi)部持有一個List,其原始為java.util.HashMap,從這個類基本可以看出是與數(shù)據(jù)庫的查詢相關(guān),對數(shù)據(jù)庫返回結(jié)果的解碼并組織成HashMap。
這個List中的元素總共有146033個,初步可以判斷出是在一次查詢中從數(shù)據(jù)庫中一次查詢出了太多數(shù)據(jù),造成了內(nèi)存溢出。
由于SQL查詢代碼中,是用HashMap來接收數(shù)據(jù)庫中的返回字段,無法一時間看出是那個查詢,那我們能不能精確找到是哪一個查詢,哪一行代碼,甚至與哪一條SQL語句呢?
答案是可以的,我們可以從視圖一探究竟。
溫馨提示:
視圖使用技巧:展開技巧:沿著使用率最高的項一層一層進行展開,直至發(fā)現(xiàn)具體占用內(nèi)存的對象。
接下來我們從 視圖去尋找是哪個方法,哪條SQL語句觸發(fā)的。
具體方法:首先完全展開一個線程,從展開圖的底部向上尋找:
其線程的入口(控制層代碼)
繼續(xù)往上查找,要找到SQL語句,應(yīng)該找到Mybatis處理結(jié)果集相關(guān)的類,如圖所示:
然后展開boundSql即能找到SQL語句:
然后鼠標可以放在SQL屬性中,右鍵,可以將SQL語句復(fù)制出來。
由于這里涉及到公司的代碼機密,故在這里不貼出具體的SQL語句。
這里根據(jù)后面的分析,原來是在做導(dǎo)出功能的時候,沒有使用分頁對數(shù)據(jù)進行分頁查詢,分頁寫入Excel文件,而是一次將全部數(shù)據(jù)查詢,導(dǎo)致導(dǎo)出功能如果并發(fā)數(shù)超過4個時,就會將所有內(nèi)存耗盡。
解決方案:
首先在運維層面將該請求導(dǎo)入到指定的一臺服務(wù)器上,是導(dǎo)出任務(wù)與其他任務(wù)進行隔離,避免對其他重要服務(wù)造成影響。
項目組對其代碼進行修復(fù),可以使用分頁查數(shù)據(jù),然后分配寫入Excel。
關(guān)于生產(chǎn)環(huán)境JVM內(nèi)存溢出的示分析就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。
分享標題:生產(chǎn)環(huán)境JVM內(nèi)存溢出的示分析
鏈接地址:http://muchs.cn/article28/pipcjp.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供企業(yè)網(wǎng)站制作、網(wǎng)頁設(shè)計公司、企業(yè)建站、云服務(wù)器、標簽優(yōu)化、定制網(wǎng)站
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)