案例3: 某財險公司運行時的Perm區內存溢出分析

文檔屬性

此文檔由東風微鳴編寫。
未經許可，不得向個人或機構傳閱或複製

修改記錄

日期	作者	版本	修改記錄
2017/4/12	東風微鳴	V1.0	創建文檔
2017/4/12	東風微鳴	V1.1	細節完善

審閱記錄

審閱人	職位

分發記錄

拷貝No.	姓名	單位
1
2
3

參考文件

參考文件

一 概述

1.1 客戶需求

1.1.1 客戶問題描述

客戶通過Dynatrace發現某臺Jboss的JVM**內存突然提交，然後垃圾回收**。如下圖。

1.1.2 客戶需求

客戶想要了解Root Cause。

1.2 收集信息概述

客戶發現Jboss的內存突然彪增，且JVM的GC時間大幅增長。查看Dynatrace發現，當時該及節點已經發生Perm區內存溢出。且有告警產生（同時應用關鍵業務錯誤率大幅增長）（Perm區內存溢出導致的OLD去彪增和GC時間彪增，具體分析見下文）。如下圖：

二 事故影響範圍

查看當時的主機、JVM及應用業務情況，該問題造成一系列的連鎖影響，包括：

• CPU利用率升高
• 物理內存升高
• JVM heap區增大
• JVM gc及掛起時間變長
• Jboss線程數上升
• 關鍵業務全部失敗
• 關鍵業務響應變慢
  具體如下圖：

2.1 主機

2.2 中間件

2.3 應用

三 問題分析及定位

3.1 我定製2個儀表圖來分析問題

具體如下圖。直接Perm OOM的原因是：類加載量的大幅增長（因爲Perm區存放的就是靜態類和常量等，而Perm OOM JDK默認會做fullgc，因此導致gc及掛起時間增加；因爲無法GC掉，會導致Heap區調整及CPU增加、線程數增加）

3.2 爲什麼加載的類會突然飆增？

我們對上圖放大，查看細節。如下圖：

類加載數量是在8:25-8:30期間大幅增長的。接下來我們需要查看這期間的該Jboss具體在做什麼業務。

3.3 查看8:25-8:30的Jboss上的purepath

purepath簡單理解：所有的事務的分佈式方法調用棧及相關信息。（如響應時間、時間細分、線程、LOG、Exception、SQL、Message等）

如下圖，直接可以看出：

• 導致該問題的root cause 事務：/RuleManager/showCalib1QueryCondition.htm
• 導致該問題的root casue代碼：c3p0(c3p0性能有問題。調用c3p0前後會有類加載的動作，正是這個情況導致了當時大量的類加載) （下圖forName0就是類加載的相關方法）
  

四 總結及優化建議

4.1 問題發生的先後順序

1. 出現大量的/RuleManager/showCalib1QueryCondition.htm請求
2. 需要加載大量的C3p0相關類
3. 類加載數量大幅增長
4. Perm區256M內存用完
5. 觸發JVM full gc
6. gc及掛起時間增加
7. 無法GC掉 → CPU增加、線程增加、Heap區增加、業務失敗

4.2 優化建議

4.2.1 中間件（治標不治本）

1. 增大Perm區大小

2. 優化與Perm清理有關的參數（如Perm滿後清理，不執行full gc等）

3. 爲了更方便的定位問題，特別是在沒有Dynatrace的情況下，建議在生產環境開啓GC日誌。

   阿里的JAVA專家說過:

   其實線上開GC日誌沒關係啦，我們線上就一直開着，對性能不會有那麼大影響的。

4.2.2 開發

• 優化JDBC相關代碼（如果想要優化c3p0代碼可以看3.3的代碼邏輯。如果不想優化建議直接不要採用c3p0作爲JDBC框架，選擇其他JDBC框架）

4.3 最後說一句

其實這個問題一個月以前就已經分析過了，但是由於當時的影響只是應用關鍵業務變慢，所以並沒有引起重視。但是這次造成的影響就比較大了，直接導致關鍵業務全部失敗以及Jboss長時間掛起（即不可用）。

所以，大的生產事故，其實可能都是因爲一些細小的，我們認爲沒關係或者可以忽略的性能問題導致的。

:punch: 生產無小事！責任大於天！