您好,登錄后才能下訂單哦!
作者:未完成交響曲
首先通過我們內部搭建的日志平臺發現我們線上環境一個java應用有大量的http接口請求超時,登錄linux服務器查看網絡環境沒有問題,判斷是應用自身運行異常,重啟應用后發現異常還在,開始查找問題。
通過指令:jstat -gcutil 查看jvm內存占用和gc情況:
發現老年代內存占用比例過高,并且每次fullGC后并沒有有效回收。老年代內存占用百分比變化趨勢大致如下:
初步判斷大量請求超時和服務癱瘓的直接原因:
每次fullGC后的內存占用越來越高
內存占用增長速度越來越快
fullGC的頻率越來越高
最終占用達到100%,服務完全癱瘓
使用指令:jmap -histo:live *** | more 查看堆內存中的對象數量和大小
發現Log4jLogEvent這個對象實例很多,占用內存也異常的大,初步分析是異步日志傳輸速度跟不上,導致日志對象堆積在內存中。
嘗試使用調整Flume傳輸日志參數:提高flume單次傳輸量,減少最大延遲時間
重啟應用并監控接口調用情況發現應用暫時恢復正常了。
在前一步分析內存的同時,使用指令:jmap -dump:format=b,file=heapDump.hprof將實時內存信息導出(dump過程比較慢,所以在問題暫時處理完后進行后續分析),使用mat分析內存結構:
可以看到主要占據堆內存的對象信息,果然是Flume異步傳輸日志堵塞的問題。
對jvm內存泄露這類問題的解決,主要是要善于利用jvm提供的類似jstat、jmap等工具來分析查找問題。這次問題雖然解決,但是后續還是存在出現此類問題的風險。所以除了加強jvm問題排查能力的同時,我們也將建立應用監控平臺的計劃提上日程,希望能對jvm內存、線程等應用實時運行指標進行監控,便于盡早發現問題。
歡迎大家一起交流,喜歡文章記得點個贊喲,感謝支持!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。