JVM快速調優手冊05:ParNew收集器+CMS收集器的產品案例分析(響應時間優先)

一.服務器: 

               雙核,4個cores;  16G memory

[root@alish2-cassandra-01 ~]# cat /proc/cpuinfo | grep "cpu cores"

cpu cores       : 2

cpu cores       : 2

 

二.公式簡述:

響應時間優先的併發收集器，主要是保證系統的響應時間，減小垃圾收集時的停頓時間。適用於應用服務器、電信領域等。

1.ParNew收集器:

     ParNew收集器是Serial收集器的多線程版本，許多運行在Server模式下的虛擬機中首選的新生代收集器，除Serial外，只有它能與CMS收集器配合工做。

2.CMS收集器:

    CMS， 全稱Concurrent Low Pause Collector，是jdk1.4後期版本開始引入的新gc算法，在jdk5和jdk6中獲得了進一步改進，

它的主要適合場景是對響應時間的重要性需求 大於對吞吐量的要求，可以承受垃圾回收線程和應用線程共享處理器資源，

而且應用中存在比較多的長生命週期的對象的應用。CMS是用於對tenured generation的回收，也就是年老代的回收，目標是儘可能減小應用的暫停時間，減小FullGC發生的概率，利用和應用程序線程併發的垃圾回收線程來 標記清除年老代。

 

CMS並不是沒有暫停，而是用兩次短暫停來替代串行標記整理算法的長暫停，它的收集週期是這樣：
    初始標記(CMS-initial-mark) -> 併發標記(CMS-concurrent-mark) -> 從新標記(CMS-remark) -> 併發清除(CMS-concurrent-sweep) ->併發重設狀態等待下次CMS的觸發(CMS-concurrent-reset)。
    其中的1，3兩個步驟須要暫停全部的應用程序線程的。第一次暫停從root對象開始標記存活的對象，這個階段稱爲初始標記；第二次暫停是在併發標記以後，暫停全部應用程序線程，從新標記併發標記階段遺漏的對象（在併發標記階段結束後對象狀態的更新致使）。第一次暫停會比較短，第二次暫停一般會比較長，而且remark這個階段能夠並行標記。

    而併發標記、併發清除、併發重設階段的所謂併發，是指一個或者多個垃圾回收線程和應用程序線程併發地運行，垃圾回收線程不會暫停應用程序的執行，若是你有多於一個處理器，那麼併發收集線程將與應用線程在不一樣的處理器上運行，顯然，這樣的開銷就是會下降應用的吞吐量。Remark階段的並行，是指暫停了全部應用程序後，啓動必定數目的垃圾回收進程進行並行標記，此時的應用線程是暫停的。

三.公式:($TOMCAT_HOME/bin/catalina.sh)

export JAVA_OPTS="-server -Xmx10240m -Xms10240m -Xmn3840m -XX:PermSize=256m

-XX:MaxPermSize=256m -Denv=denalicnprod

-XX:SurvivorRatio=8  -XX:PretenureSizeThreshold=1048576

-XX:+DisableExplicitGC  

-XX:+UseParNewGC  -XX:ParallelGCThreads=10

-XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled

-XX:+CMSScavengeBeforeRemark -XX:ParallelCMSThreads=10

-XX:CMSInitiatingOccupancyFraction=70

-XX:+UseCMSInitiatingOccupancyOnly

-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0

-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

-XX:+UseFastAccessorMethods

-XX:LargePageSizeInBytes=128M

-XX:SoftRefLRUPolicyMSPerMB=0

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC

-XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps -Xloggc:gc.log -verbose:gc"

 

四.公式解析:

-server	必定要做爲第一個參數，啓用JDK的server版本，在多個CPU時性能佳
-Xms	java Heap初始大小。 默認是物理內存的1/64。此值能夠設置與-Xmx相同，以免每次垃圾回收完成後JVM從新分配內存。
-Xmx	java heap最大值。建議均設爲物理內存的80%。不可超過物理內存。
-Xmn	設置年輕代大小，通常設置爲Xmx的2/8~3/8,等同於-XX:NewSize 和 -XX:MaxNewSize  。
-XX:PermSize	設定內存的永久保存區初始大小，缺省值爲64M
-XX:MaxPermSize	設定內存的永久保存區最大大小，缺省值爲64M
-Denv	指定tomcat運行哪一個project
-XX:SurvivorRatio	Eden區與Survivor區的大小比值, 設置爲8,則兩個Survivor區與一個Eden區的比值爲2:8,一個Survivor區佔整個年輕代的1/10
-XX:PretenureSizeThreshold	晉升年老代的對象大小。默認爲0，好比設爲1048576(1M)，則超過1M的對象將不在eden區分配，而直接進入年老代。
-XX:+DisableExplicitGC	關閉System.gc()
-XX:+UseParNewGC	設置年輕代爲併發收集。可與CMS收集同時使用。
-XX:ParallelGCThreads
-XX:+UseConcMarkSweepGC	設置年老代爲併發收集。測試中配置這個之後，-XX:NewRatio=4的配置失效了。因此，此時年輕代大小最好用-Xmn設置。
-XX:+CMSParallelRemarkEnabled	開啓並行remark
-XX:+CMSScavengeBeforeRemark	這個參數還蠻重要的，它的意思是在執行CMS remark以前進行一次youngGC，這樣能有效下降remark的時間
-XX:ParallelCMSThreads	CMS默認啓動的回收線程數目是  (ParallelGCThreads + 3)/4) ，若是你須要明確設定，能夠經過-XX:ParallelCMSThreads=20來設定,其中ParallelGCThreads是年輕代的並行收集線程數
-XX:CMSInitiatingOccupancyFraction	使用cms做爲垃圾回收使用70％後開始CMS收集
-XX:+UseCMSInitiatingOccupancyOnly	使用手動定義初始化定義開始CMS收集
-XX:+UseCMSCompactAtFullCollection	打開對年老代的壓縮。可能會影響性能，可是能夠消除內存碎片。
-XX:CMSFullGCsBeforeCompaction	因爲併發收集器不對內存空間進行壓縮、整理，因此運行一段時間之後會產生「碎片」，使得運行效率下降。此參數設置運行次FullGC之後對內存空間進行壓縮、整理。
-XX:+CMSPermGenSweepingEnabled	爲了不Perm區滿引發的full gc，建議開啓CMS回收Perm區選項
-XX:+CMSClassUnloadingEnabled
-XX:+UseFastAccessorMethods	原始類型的快速優化
-XX:LargePageSizeInBytes	內存頁的大小，不可設置過大， 會影響Perm的大小
-XX:SoftRefLRUPolicyMSPerMB	「軟引用」的對象在最後一次被訪問後能存活0毫秒（默認爲1秒）。
-XX:+PrintGCDetails	記錄 GC 運行時的詳細數據信息，包括新生成對象的佔用內存大小以及耗費時間等
-XX:+PrintGCTimeStamps	打印垃圾收集的時間戳
-XX:+PrintHeapAtGC	打印GC先後的詳細堆棧信息
-XX:+PrintGCApplicationStoppedTime	打印垃圾回收期間程序暫停的時間.可與上面混合使用
-XX:+PrintGCDateStamps	以前打印gc日誌的時候使用是：-XX:+PrintGCTimeStamps，這個選項記錄的是jvm啓動時間爲起點的相對時間，可讀性較差，不利於定位問題，使用PrintGCDateStamps記錄的是系統時間，更humanreadable
-Xloggc	與上面幾個配合使用，把相關日誌信息記錄到文件以便分析
-verbose:gc	記錄 GC 運行以及運行時間，通常用來查看 GC 是不是應用的瓶頸