jvm間歇性崩潰分析

http://www.cnblogs.com/LBSer/p/4417148.html

1 問題描述     

      某服務有兩臺機器，每隔幾天會報警load高，一開始看監控發現gc時間抖動很大，覺得是發生了fullgc引發卡頓而未加註意，以後登入線上機器查看日誌發現是jvm崩潰致使了服務重啓從而引起gc時間抖動。以某天爲例，該服務分別在上午7點和上午10點發生jvm崩潰，若是同時發生崩潰將致使線上停服，後果不堪設想。

2 問題分析

     崩潰日誌顯示jvm崩潰發生在在標記清除掃根路徑時。

     搜索此bug，發現是jvm的一個已知bug，https://bugs.openjdk.java.net/browse/JDK-8020236，這個bug在1.6和1.7中均有，只是由於重現困難而一直未被修復。

                Par_MarkFromRootsClosure::scan_oops_in_oop(HeapWord*)

 

      有人遇到和咱們同樣的問題（http://hllvm.group.iteye.com/group/topic/43404），他經過壓測發現當「ParallelCMSThreads > ParallelGCThreads」會引發此崩潰，而當"ParallelCMSThreads <= ParallelGCThreads"時問題再也不復現。而「ParallelCMSThreads > ParallelGCThreads」這個問題也在jvm bug列表中（https://bugs.openjdk.java.net/browse/JDK-6668573），此bug下有人給出的解決思路是將ParallelCMSThreads 設置爲 <=ParallelGCThreads。

3 解決方法

        查看咱們junglepoi-service服務的jvm參數配置，發現ParallelCMSThreads被設置成4，而ParallelGCThreads卻未被設置。默認狀況下ParallelGCThreads = (ncpus <= 8) ? ncpus : 3 + ((ncpus * 5) / 8)，其中ncpus是機器的核數，因爲junglepoi-service服務所在的機器爲2核4G配置，所以默認狀況下ParallelGCThreads=2，此時ParallelCMSThreads > ParallelGCThreads。       

       解決方法是：1）將ParallelCMSThreads設置爲2或1；2）或者不設置ParallelCMSThreads，默認狀況下ParallelCMSThreads = (ParallelGCThreads + 3) / 4，若是不設置默認ParallelCMSThreads=(2+3)/4=1。

       咱們將ParallelCMSThreads設置爲2，上線兩天未復現jvm崩潰異常，後續將持續觀察。

4 啓示

       不能簡單拷貝其它項目的jvm參數配置，須要結合項目特色、機器環境等各方面信息來綜合配置。