JVM快速調優手冊v1.0之五: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 是否是應用的瓶頸 |
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31537832/viewspace-2154706/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- JVM快速調優手冊v1.0之二:常見的垃圾收集器JVM
- JVM快速調優手冊v1.0JVM
- JVM快速調優手冊v1.0之六:JVM引數設定、分析JVM
- JVM快速調優手冊v1.0之四:堆記憶體分配的CMS公式解析JVM記憶體公式
- JVM調優:HotSpot JVM垃圾收集器JVMHotSpot
- JVM快速調優手冊v1.0之三:記憶體分配策略JVM記憶體
- 記一次jvm調優及垃圾收集器JVM
- JVM(五)-垃圾收集器入門JVM
- mysql優化手冊v1.0MySql優化
- 深入理解 JVM 之 垃圾收集器JVM
- CMS、G1收集器
- JVM垃圾收集器(八)JVM
- Oracle效能優化方法論的發展之五:基於工作單元的響應時間分析的效能優化方法論Oracle優化
- JVM之調優及常見場景分析JVM
- JVM垃圾收集器總結JVM
- JVM垃圾收集器專題JVM
- JVM 經典垃圾收集器JVM
- 【金三銀四-JVM系列】CMS收集器與GC日誌分析定位問題詳解JVMGC
- 自走棋手遊前瞻:產品優先or市場優先?
- “時間”都去哪兒了?效能調優分析方法與案例詳解
- Oracle效能優化方法論的發展之六:基於流程分析和響應時間分析的效能優化方法論Oracle優化
- JVM調優JVM
- 【JAVA進階架構師指南】之五:JVM效能調優Java架構JVM
- 快速響應及時調優,瞭解手遊動態運營的核心原則
- JVM面試問題系列:7種JVM垃圾收集器特點,優劣勢、及使用場景!JVM面試
- 一次快速排序引發的jvm調優排序JVM
- 探探Java之 JVM GC與調優JavaJVMGC
- 移動優先的響應式佈局
- JVM調優策略JVM
- 一次生產的 JVM 優化案例JVM優化
- 記一次 500併發,平均響應時間慢-調優過程~~
- JVM效能調優,記憶體分析工具JVM記憶體
- "簡單"的jvm調優JVM
- “簡單”的jvm調優JVM
- JVM調優引數、方法、工具以及案例總結JVM
- Oracle效能優化方法論的發展之三:基於響應時間分析的效能優化方法論Oracle優化
- 深入理解JVM,7種垃圾收集器JVM
- JVM——垃圾收集器與記憶體分配JVM記憶體