1. 程式人生 > >CMS gc 實踐總結

CMS gc 實踐總結

   CMS,全稱Concurrent low pause collector,是jdk1.4後期版本開始引入的新gc演算法,在jdk5和jdk6中得到了進一步的改進,它的主要適合場景是對響應實踐的重要性需求大於吞吐量的要求,能夠承受垃圾回收執行緒和應用執行緒共享處理器資源,並且應用中存在比較多的長生命週期的物件的應用。CMS是用於對tenured generation的回收,也就是年老代的回收,目標是儘量減少應用的暫停時間,減少full gc發生的機率,利用和應用程式執行緒併發的垃圾回收執行緒來標記清楚年老代。在我們的應用中,因為有快取的存在,並且對於響應時間也有比較高的要求,因此希望能夠嘗試使用CMS來替代預設的server型JVM使用的並行收集器,以便獲得更短的垃圾回收的暫停時間,提高程式的響應性。

  CMS並非沒有暫停,只是用兩次短暫停來替代序列標記整理演算法的長暫停,它的收集週期是這樣的:

   初始標記(cms-initial-mark)->併發標記(cms-concurrent-mark)->重新標記(cms-remark)->併發清除(cms-concurrent-sweep)->併發重設狀態等待下次cms的觸發(cms-concurrent-reset).

    其中的1,3兩個步驟需要暫停所有的應用程式執行緒的。第一次暫停從root物件開始標記存活的物件,這個階段稱為初始標記;第二次暫停是在併發標記之後,暫停所有應用程式執行緒,重新標記併發標記階段遺漏的物件(在併發標記階段結束後物件的更新導致)。第一次暫停時間比較短,第二次暫停通常比較長,並且remark這個階段可以並行標記。

     而併發標記,併發清除,併發重設階段的所謂併發,是指一個或者多個垃圾回收執行緒和應用程式併發地執行,垃圾回收執行緒不會暫停應用程式的執行,如果你有多於一個處理器,那麼併發收集器執行緒將與應用程式執行緒再不同的處理器上執行,顯然這樣的開銷就是會降低應用的吞吐量。Remark階段的並行,是指暫停了所有的應用程式後,啟動一定數目的垃圾回收進行進行並行標記,此時應用執行緒是暫停的。

 CMS的young generation的回收採用的仍然是並行複製收集器,這個跟Paralle gc演算法是一致的。

下面是引數介紹和遇到的問題總結:

1、啟用CMS:-XX:+UseConcMarkSweepGC


2.

2。CMS預設啟動的回收執行緒數目是  (ParallelGCThreads + 3)/4) ,如果你需要明確設定,可以通過-XX:ParallelCMSThreads=20來設定,其中ParallelGCThreads是年輕代的並行收集執行緒數


3、CMS是不會整理堆碎片的,因此為了防止堆碎片引起full gc,通過會開啟CMS階段進行合併碎片選項:-XX:+UseCMSCompactAtFullCollection,開啟這個選項一定程度上會影響效能,阿寶的blog裡說也許可以通過配置適當的CMSFullGCsBeforeCompaction來調整效能,未實踐。

4.為了減少第二次暫停的時間,開啟並行remark: -XX:+CMSParallelRemarkEnabled。如果remark還是過長的話,可以開啟-XX:+CMSScavengeBeforeRemark選項,強制remark之前開始一次minor gc,減少remark的暫停時間,但是在remark之後也將立即開始又一次minor gc。

5.為了避免Perm區滿引起的full gc,建議開啟CMS回收Perm區選項:

+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled


6.預設CMS是在tenured generation沾滿68%的時候開始進行CMS收集,如果你的年老代增長不是那麼快,並且希望降低CMS次數的話,可以適當調高此值:
-XX:CMSInitiatingOccupancyFraction=80

這裡修改成80%沾滿的時候才開始CMS回收。

7.年輕代的並行收集執行緒數預設是(cpu <= 8) ? cpu : 3 + ((cpu * 5) / 8),如果你希望降低這個執行緒數,可以通過-XX:ParallelGCThreads= N 來調整。

8.進入重點,在初步設定了一些引數後,例如:

Java程式碼  收藏程式碼
  1. -server -Xms1536m -Xmx1536m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:PermSize=64m  
  2. -XX:MaxPermSize=64m -XX:-UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection  
  3. -XX:CMSInitiatingOccupancyFraction=80 -XX:+CMSParallelRemarkEnabled  
  4. -XX:SoftRefLRUPolicyMSPerMB=0  

需要在生產環境或者壓測環境中測量這些引數下系統的表現,這時候需要開啟GC日誌檢視具體的資訊,因此加上引數:

-verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/home/test/logs/gc.log

在執行相當長一段時間內檢視CMS的表現情況,CMS的日誌輸出類似這樣:

Java程式碼  收藏程式碼
  1. 4391.322: [GC [1 CMS-initial-mark: 655374K(1310720K)] 662197K(1546688K), 0.0303050 secs] [Times: user=0.02 sys=0.02, real=0.03 secs]  
  2. 4391.352: [CMS-concurrent-mark-start]  
  3. 4391.779: [CMS-concurrent-mark: 0.427/0.427 secs] [Times: user=1.24 sys=0.31, real=0.42 secs]  
  4. 4391.779: [CMS-concurrent-preclean-start]  
  5. 4391.821: [CMS-concurrent-preclean: 0.040/0.042 secs] [Times: user=0.13 sys=0.03, real=0.05 secs]  
  6. 4391.821: [CMS-concurrent-abortable-preclean-start]  
  7. 4392.511: [CMS-concurrent-abortable-preclean: 0.349/0.690 secs] [Times: user=2.02 sys=0.51, real=0.69 secs]  
  8. 4392.516: [GC[YG occupancy: 111001 K (235968 K)]4392.516: [Rescan (parallel) , 0.0309960 secs]4392.547: [weak refs processing, 0.0417710 secs] [1 CMS-remark: 655734K(1310720K)] 766736K(1546688K), 0.0932010 secs] [Times: user=0.17 sys=0.00, real=0.09 secs]  
  9. 4392.609: [CMS-concurrent-sweep-start]  
  10. 4394.310: [CMS-concurrent-sweep: 1.595/1.701 secs] [Times: user=4.78 sys=1.05, real=1.70 secs]  
  11. 4394.310: [CMS-concurrent-reset-start]  
  12. 4394.364: [CMS-concurrent-reset: 0.054/0.054 secs] [Times: user=0.14 sys=0.06, real=0.06 secs]  


其中可以看到CMS-initial-mark階段暫停了0.0303050秒,而CMS-remark階段暫停了0.0932010秒,因此兩次暫停的總共時間是0.123506秒,也就是123毫秒左右。兩次短暫停的時間之和在200以下可以稱為正常現象。

但是你很可能遇到兩種fail引起full gc:Prommotion failed和Concurrent mode failed。

Prommotion failed的日誌輸出大概是這樣:

Java程式碼  收藏程式碼
  1. [ParNew (promotion failed): 320138K->320138K(353920K), 0.2365970 secs]42576.951: [CMS: 1139969K->1120688K(  
  2. 166784K), 9.2214860 secs] 1458785K->1120688K(2520704K), 9.4584090 secs]  


這個問題的產生是由於救助空間不夠,從而向年老代轉移物件,年老代沒有足夠的空間來容納這些物件,導致一次full gc的產生。解決這個問題的辦法有兩種完全相反的傾向:增大救助空間、增大年老代或者去掉救助空間。 增大救助空間就是調整-XX:SurvivorRatio引數,這個引數是Eden區和Survivor區的大小比值,預設是32,也就是說Eden區是 Survivor區的32倍大小,要注意Survivo是有兩個區的,因此Surivivor其實佔整個young genertation的1/34。調小這個引數將增大survivor區,讓物件儘量在survitor區呆長一點,減少進入年老代的物件。去掉救助空 間的想法是讓大部分不能馬上回收的資料儘快進入年老代,加快年老代的回收頻率,減少年老代暴漲的可能性,這個是通過將-XX:SurvivorRatio 設定成比較大的值(比如65536)來做到。在我們的應用中,將young generation設定成256M,這個值相對來說比較大了,而救助空間設定成預設大小(1/34),從壓測情況來看,沒有出現prommotion failed的現象,年輕代比較大,從GC日誌來看,minor gc的時間也在5-20毫秒內,還可以接受,因此暫不調整。

Concurrent mode failed的產生是由於CMS回收年老代的速度太慢,導致年老代在CMS完成前就被沾滿,引起full gc,避免這個現象的產生就是調小-XX:CMSInitiatingOccupancyFraction引數的值,讓CMS更早更頻繁的觸發,降低年老代被沾滿的可能。我們的應用暫時負載比較低,在生產環境上年老代的增長非常緩慢,因此暫時設定此引數為80。在壓測環境下,這個引數的表現還可以,沒有出現過Concurrent mode failed。