如何優(yōu)化JVMOOM

這篇文章主要講解了“如何優(yōu)化JVM OOM”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“如何優(yōu)化JVM OOM”吧！

創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),石獅企業(yè)網(wǎng)站建設(shè),石獅品牌網(wǎng)站建設(shè),網(wǎng)站定制,石獅網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,石獅網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。

剛接手的服務(wù)，正常穩(wěn)定運行了很長一段時間，在大家伙收拾東西準(zhǔn)備回家過年時，突然就抽風(fēng)了。

接口失敗率居高不下？

看日志！

GC overhead limit exceeded          

java.lang.OutOfMemoryError：GC overhead limit exceeded          

看一下JVM堆棧

sudo jmap -heap port        

#eg：sudo jmap -heap 9999        

很明顯，是內(nèi)存不夠了。

我當(dāng)時的第一想法就是，應(yīng)該是內(nèi)存泄漏！我的思路如下：

1、先入為主，因為之前處理過一次因內(nèi)存泄漏導(dǎo)致的JVM OOM問題，所以當(dāng)時高度懷疑內(nèi)存泄漏。

2、導(dǎo)出JVM堆數(shù)據(jù)，分析、定位問題。

3、fix bug，重新部署，finish!

我按照這個思路，分析堆棧后，發(fā)現(xiàn)堆中有大量對象，這些對象還沒來得及回收，其他線程又在申請內(nèi)存，從而導(dǎo)致了OOM。造成問題的直接原因是業(yè)務(wù)請求量增加了，而現(xiàn)有的機(jī)器資源不夠用。至于間接原因，下一篇文章再詳細(xì)描述。

在揭開問題的謎底后，回過頭想一想，如果當(dāng)時能夠仔細(xì)分析一下問題，或許問題會被更快解決。

事后反思：服務(wù)已經(jīng)穩(wěn)定正常運行了一段時間，且一個月內(nèi)未修改代碼和更新服務(wù)。如果是代碼有問題，那么問題極大可能會在新代碼上線后的幾天內(nèi)出現(xiàn)?；谶@一點，基本可以排除代碼問題。

線上服務(wù)出現(xiàn)問題，首要的任務(wù)就是盡快恢復(fù)服務(wù)可用。如果下次出現(xiàn)類似問題，我會選擇流程一，而非流程二。

造成服務(wù)不可用的直接原因是服務(wù)請求量上升，而根本原因是由于下游服務(wù)負(fù)載過高，導(dǎo)致微服務(wù)調(diào)用超時，從而引起連鎖反應(yīng)。

下圖呈現(xiàn)了用戶發(fā)起請求到響應(yīng)完成的大致流程。

業(yè)務(wù)服務(wù)接口和算法服務(wù)接口使用eureka作為服務(wù)注冊中心，整體來說，這個服務(wù)采用相對簡單的微服務(wù)架構(gòu)。

服務(wù)接口搭配feign來請求算法服務(wù)接口。

@FeignClient(value = "image-service")        

public interface ImageService {        

@PostMapping(value = "/XXX")        

String XXX(@RequestParam("img_base64") String imgBase64);        

}        

上面的代碼在執(zhí)行請求的時候，會將請求參數(shù)進(jìn)行拼接。

image-service/xxx?img_base64=fjsfdgldfgrwdfdmgfdglwefsl        

當(dāng)eureka真正確定請求的服務(wù)地址后，又會再做一次拼接處理。

127.0.0.1:5000/xxx?img_base64=fjsfdgldfgrwdfdmgfdglwefsl        

算法服務(wù)接口的處理時間與圖片的大小正相關(guān)，圖片越大，處理時間越長。由于處理圖片是一個相對耗時的操作，接口會出現(xiàn)超時的情況。如果請求失?。ǔ瑫r），那么feign會進(jìn)行重試。

圖片base64字符串的長度與圖片大小呈正相關(guān)關(guān)系，圖片越大，base64字符串長度越長。一張306K的圖片，轉(zhuǎn)成base64格式后，字符串長度為429196。

因此處理一次正常的請求消耗的內(nèi)存比較大。圖片越大，算法處理時間越久，超時失敗后，feign重試，重試之后又失敗，導(dǎo)致一個惡性循環(huán)（幸好有超時次數(shù)限制，否則如此遞歸下去，后果不堪設(shè)想）。

如圖是JVM OOM后拿到堆棧的數(shù)據(jù)，最大的圖片base64的大小有5M。

jdk1.8 JVM參數(shù)PretenureSizeThreshold的默認(rèn)值是2M。

當(dāng)base64字符串超過2M時，會直接分配到老年代，這無疑加大了JVM老年代的內(nèi)存壓力，導(dǎo)致頻繁Full GC。

為何使用image base64傳輸圖片？

1、歷史原因。

2、開發(fā)相對簡單。

該如何優(yōu)化？

1、提高feign請求的超時時間。

2、提高機(jī)器配置。

3、將image base64放到請求體中，減少因feign框架對參數(shù)進(jìn)行拼接帶來的內(nèi)存開銷。

感謝各位的閱讀，以上就是“如何優(yōu)化JVM OOM”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對如何優(yōu)化JVM OOM這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！

文章標(biāo)題：如何優(yōu)化JVMOOM
文章鏈接：http://muchs.cn/article30/gddepo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App設(shè)計、Google、企業(yè)建站、品牌網(wǎng)站設(shè)計、網(wǎng)頁設(shè)計公司、網(wǎng)站設(shè)計公司

廣告

聲明：本網(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)