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

superjack2發表於2018-05-18

.伺服器: 

               雙核,4cores;  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演算法,在jdk5jdk6中得到了進一步改進,

它的主要適合場景是對響應時間的重要性需求 大於對吞吐量的要求,能夠承受垃圾回收執行緒和應用執行緒共享處理器資源,

並且應用中存在比較多的長生命週期的物件的應用。CMS是用於對tenured generation的回收,也就是年老代的回收,目標是儘量減少應用的暫停時間,減少FullGC發生的機率,利用和應用程式執行緒併發的垃圾回收執行緒來 標記清除年老代。

 

CMS並非沒有暫停,而是用兩次短暫停來替代序列標記整理演算法的長暫停,它的收集週期是這樣:
    初始標記(CMS-initial-mark) -> 併發標記(CMS-concurrent-mark) -> 重新標記(CMS-remark) -> 併發清除(CMS-concurrent-sweep) ->併發重設狀態等待下次CMS的觸發(CMS-concurrent-reset)
    其中的13兩個步驟需要暫停所有的應用程式執行緒的。第一次暫停從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

一定要作為第一個引數,啟用JDKserver版本,在多個CPU時效能佳

-Xms

java Heap初始大小。 預設是實體記憶體的1/64此值可以設定與-Xmx相同,以避免每次垃圾回收完成後JVM重新分配記憶體。

-Xmx

java heap最大值。建議均設為實體記憶體的80%。不可超過實體記憶體。

-Xmn

設定年輕代大小,一般設定為Xmx2/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 是否是應用的瓶


 

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31537832/viewspace-2154706/,如需轉載,請註明出處,否則將追究法律責任。

相關文章