jvm問題實錄2-線上堆內存使用率告警

線上現象(來自凌晨的問候)

1. 凌晨3點線上項目在監控平臺上開始報警（jvm堆內存佔用報警超過80%，持續報警）

   

2. 觀察具體的監控圖標（線程數平穩） 時間:2019-06-13 首先要看方法調用量有沒有大量提高，經過排查沒有

   

   

   

   

邏輯分析(定位問題大體方向)

1. 經過當天監控數據分析，堆內存持續上升，在凌晨3點左右觸及報警配置水位1800/2048 >80%,致使報警
2. 非堆、cpu、線程數穩定
3. 系統Young GC頻繁，Full GC暫時沒有

當前推論 ：系統YGC已經不能回收太多堆內存，而FGC尚未執行，可能是由於老年代在持續增加，

須要查看當前機器自啓動以來的歷史數據參考(由於當前線上一次查詢範圍最大1天)， 2019-06-10 ->11號 數據，和12號的比對，能夠看出堆內存水位在緩慢上升,最終再13號凌晨出發報警。

接着推論 ：

1. 老年代持續上升，按照CMS的默認92%處理機制，若是是正常內存使用，咱們不用管報警，達到高水位自動FGC,堆內存恢復低位，
2. 可是若是是由於內存泄露引發的問題，那麼按照目前速率可能會在2-3天后（也多是618促銷期間）出現內存溢出宕機。

   

線上驗證

驗證以前要當心，最好先把機器從集羣摘除，由於FullGC會影響機器性能 接下來咱們要驗證一下是正常的使用仍是內存泄露，採用手動觸發一次FGC，執行histo命令

結論： 從監控能夠看出，觸發了FGC後,堆內存直接降到低水位，所以咱們能夠理解爲是正常的內存增加，

後續的工做 ： 1. 從dump及代碼層面分析爲何老年代持續增加， 2. 更改一下監控報警配置 等優化

咱們也能夠經過監控看到剛纔執行的FGC對方法性能的影響，

後記

講個細節（爲何凌晨會持續報警）？

1. 報警規則

   

2. 長期運行後正好遇上了凌晨....
3. 凌晨調用量小，YGC間隔大，內存在間隔期長時間高水位

   

   

   troube shooting 三要素： 鍛鍊本身的邏輯思惟、鍛鍊本身的技術能力、多看多查