72.JVM參數(shù)設(shè)置、分析

JVM系列三:JVM參數(shù)設(shè)置、分析

不管是YGC還是Full GC,GC過程中都會(huì)對(duì)導(dǎo)致程序運(yùn)行中中斷,正確的選擇不同的GC策略,調(diào)整JVM、GC的參數(shù)，可以極大的減少由于GC工作，而導(dǎo)致的程序運(yùn)行中斷方面的問題，進(jìn)而適當(dāng)?shù)奶岣逬ava程序的工作效率。但是調(diào)整GC是以個(gè)極為復(fù)雜的過程，由于各個(gè)程序具備不同的特點(diǎn)，如：web和GUI程序就有很大區(qū)別（Web可以適當(dāng)?shù)耐ｎD，但GUI停頓是客戶無法接受的），而且由于跑在各個(gè)機(jī)器上的配置不同（主要cup個(gè)數(shù)，內(nèi)存不同），所以使用的GC種類也會(huì)不同(如何選擇見GC種類及如何選擇)。本文將注重介紹JVM、GC的一些重要參數(shù)的設(shè)置來提高系統(tǒng)的性能。

JVM內(nèi)存組成及GC相關(guān)內(nèi)容請(qǐng)見之前的文章:JVM內(nèi)存組成 GC策略&內(nèi)存申請(qǐng)。
JVM參數(shù)的含義 實(shí)例見實(shí)例分析






GC性能方面的考慮
對(duì)于GC的性能主要有2個(gè)方面的指標(biāo)：吞吐量throughput（工作時(shí)間不算gc的時(shí)間占總的時(shí)間比）和暫停pause（gc發(fā)生時(shí)app對(duì)外顯示的無法響應(yīng)）。

Total Heap
默認(rèn)情況下，vm會(huì)增加/減少heap大小以維持free space在整個(gè)vm中占的比例，這個(gè)比例由MinHeapFreeRatio和MaxHeapFreeRatio指定。
一般而言，server端的app會(huì)有以下規(guī)則：
?對(duì)vm分配盡可能多的memory；
?將Xms和Xmx設(shè)為一樣的值。如果虛擬機(jī)啟動(dòng)時(shí)設(shè)置使用的內(nèi)存比較小，這個(gè)時(shí)候又需要初始化很多對(duì)象，虛擬機(jī)就必須重復(fù)地增加內(nèi)存。
?處理器核數(shù)增加，內(nèi)存也跟著增大。

The Young Generation
另外一個(gè)對(duì)于app流暢性運(yùn)行影響的因素是young generation的大小。young generation越大，minor collection越少；但是在固定heap size情況下，更大的young generation就意味著小的tenured generation，就意味著更多的major collection(major collection會(huì)引發(fā)minor collection)。

NewRatio反映的是young和tenured generation的大小比例。NewSize和MaxNewSize反映的是young generation大小的下限和上限，將這兩個(gè)值設(shè)為一樣就固定了young generation的大小（同Xms和Xmx設(shè)為一樣）。

如果希望，SurvivorRatio也可以優(yōu)化survivor的大小，不過這對(duì)于性能的影響不是很大。SurvivorRatio是eden和survior大小比例。
一般而言，server端的app會(huì)有以下規(guī)則：
?首先決定能分配給vm的最大的heap size，然后設(shè)定最佳的young generation的大小；
?如果heap size固定后，增加young generation的大小意味著減小tenured generation大小。讓tenured generation在任何時(shí)候夠大，能夠容納所有l(wèi)ive的data（留10%-20%的空余）。

經(jīng)驗(yàn)&&規(guī)則
1.年輕代大小選擇
?響應(yīng)時(shí)間優(yōu)先的應(yīng)用:盡可能設(shè)大,直到接近系統(tǒng)的最低響應(yīng)時(shí)間限制(根據(jù)實(shí)際情況選擇).在此種情況下,年輕代收集發(fā)生的頻率也是最小的.同時(shí),減少到達(dá)年老代的對(duì)象.
?吞吐量?jī)?yōu)先的應(yīng)用:盡可能的設(shè)置大,可能到達(dá)Gbit的程度.因?yàn)閷?duì)響應(yīng)時(shí)間沒有要求,垃圾收集可以并行進(jìn)行,一般適合8CPU以上的應(yīng)用.
?避免設(shè)置過小.當(dāng)新生代設(shè)置過小時(shí)會(huì)導(dǎo)致:1.YGC次數(shù)更加頻繁 2.可能導(dǎo)致YGC對(duì)象直接進(jìn)入舊生代,如果此時(shí)舊生代滿了,會(huì)觸發(fā)FGC.
2.年老代大小選擇
0.響應(yīng)時(shí)間優(yōu)先的應(yīng)用:年老代使用并發(fā)收集器,所以其大小需要小心設(shè)置,一般要考慮并發(fā)會(huì)話率和會(huì)話持續(xù)時(shí)間等一些參數(shù).如果堆設(shè)置小了,可以會(huì)造成內(nèi)存碎 片,高回收頻率以及應(yīng)用暫停而使用傳統(tǒng)的標(biāo)記清除方式;如果堆大了,則需要較長(zhǎng)的收集時(shí)間.最優(yōu)化的方案,一般需要參考以下數(shù)據(jù)獲得:
并發(fā)垃圾收集信息、持久代并發(fā)收集次數(shù)、傳統(tǒng)GC信息、花在年輕代和年老代回收上的時(shí)間比例。
1.吞吐量?jī)?yōu)先的應(yīng)用:一般吞吐量?jī)?yōu)先的應(yīng)用都有一個(gè)很大的年輕代和一個(gè)較小的年老代.原因是,這樣可以盡可能回收掉大部分短期對(duì)象,減少中期的對(duì)象,而年老代盡存放長(zhǎng)期存活對(duì)象.
3.較小堆引起的碎片問題
因?yàn)槟昀洗牟l(fā)收集器使用標(biāo)記,清除算法,所以不會(huì)對(duì)堆進(jìn)行壓縮.當(dāng)收集器回收時(shí),他會(huì)把相鄰的空間進(jìn)行合并,這樣可以分配給較大的對(duì)象.但是,當(dāng)堆空間較小時(shí),運(yùn)行一段時(shí)間以后,就會(huì)出現(xiàn)"碎片",如果并發(fā)收集器找不到足夠的空間,那么并發(fā)收集器將會(huì)停止,然后使用傳統(tǒng)的標(biāo)記,清除方式進(jìn)行回收.如果出現(xiàn)"碎片",可能需要進(jìn)行如下配置:

-XX:+UseCMSCompactAtFullCollection:使用并發(fā)收集器時(shí),開啟對(duì)年老代的壓縮. -XX:CMSFullGCsBeforeCompaction=0:上面配置開啟的情況下,這里設(shè)置多少次Full GC后,對(duì)年老代進(jìn)行壓縮

4.用64位操作系統(tǒng)，Linux下64位的jdk比32位jdk要慢一些，但是吃得內(nèi)存更多，吞吐量更大
5.XMX和XMS設(shè)置一樣大，MaxPermSize和MinPermSize設(shè)置一樣大，這樣可以減輕伸縮堆大小帶來的壓力
6.使用CMS的好處是用盡量少的新生代，經(jīng)驗(yàn)值是128M－256M， 然后老生代利用CMS并行收集， 這樣能保證系統(tǒng)低延遲的吞吐效率。 實(shí)際上cms的收集停頓時(shí)間非常的短，2G的內(nèi)存， 大約20－80ms的應(yīng)用程序停頓時(shí)間
7.系統(tǒng)停頓的時(shí)候可能是GC的問題也可能是程序的問題，多用jmap和jstack查看，或者killall -3 java，然后查看java控制臺(tái)日志，能看出很多問題。(相關(guān)工具的使用方法將在后面的blog中介紹)
8.仔細(xì)了解自己的應(yīng)用，如果用了緩存，那么年老代應(yīng)該大一些，緩存的HashMap不應(yīng)該無限制長(zhǎng)，建議采用LRU算法的Map做緩存，LRUMap的最大長(zhǎng)度也要根據(jù)實(shí)際情況設(shè)定。
9.采用并發(fā)回收時(shí)，年輕代小一點(diǎn)，年老代要大，因?yàn)槟昀洗笥玫氖遣l(fā)回收，即使時(shí)間長(zhǎng)點(diǎn)也不會(huì)影響其他程序繼續(xù)運(yùn)行，網(wǎng)站不會(huì)停頓
10.JVM參數(shù)的設(shè)置(特別是 –Xmx –Xms –Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold等參數(shù)的設(shè)置沒有一個(gè)固定的公式，需要根據(jù)PV old區(qū)實(shí)際數(shù)據(jù) YGC次數(shù)等多方面來衡量。為了避免promotion faild可能會(huì)導(dǎo)致xmn設(shè)置偏小，也意味著YGC的次數(shù)會(huì)增多，處理并發(fā)訪問的能力下降等問題。每個(gè)參數(shù)的調(diào)整都需要經(jīng)過詳細(xì)的性能測(cè)試，才能找到特定應(yīng)用的最佳配置。

promotion failed:
垃圾回收時(shí)promotion failed是個(gè)很頭痛的問題，一般可能是兩種原因產(chǎn)生，第一個(gè)原因是救助空間不夠，救助空間里的對(duì)象還不應(yīng)該被移動(dòng)到年老代，但年輕代又有很多對(duì)象需要放入救助空間；第二個(gè)原因是年老代沒有足夠的空間接納來自年輕代的對(duì)象；這兩種情況都會(huì)轉(zhuǎn)向Full GC，網(wǎng)站停頓時(shí)間較長(zhǎng)。
解決方方案一：
第一個(gè)原因我的最終解決辦法是去掉救助空間，設(shè)置-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0即可，第二個(gè)原因我的解決辦法是設(shè)置CMSInitiatingOccupancyFraction為某個(gè)值（假設(shè)70），這樣年老代空間到70%時(shí)就開始執(zhí)行CMS，年老代有足夠的空間接納來自年輕代的對(duì)象。
解決方案一的改進(jìn)方案：
又有改進(jìn)了，上面方法不太好，因?yàn)闆]有用到救助空間，所以年老代容易滿，CMS執(zhí)行會(huì)比較頻繁。我改善了一下，還是用救助空間，但是把救助空間加大，這樣也不會(huì)有promotion failed。具體操作上，32位Linux和64位Linux好像不一樣，64位系統(tǒng)似乎只要配置MaxTenuringThreshold參數(shù)，CMS還是有暫停。為了解決暫停問題和promotion failed問題，最后我設(shè)置-XX:SurvivorRatio=1 ，并把MaxTenuringThreshold去掉，這樣即沒有暫停又不會(huì)有promotoin failed，而且更重要的是，年老代和永久代上升非常慢（因?yàn)楹枚鄬?duì)象到不了年老代就被回收了），所以CMS執(zhí)行頻率非常低，好幾個(gè)小時(shí)才執(zhí)行一次，這樣，服務(wù)器都不用重啟了。
-Xmx4000M -Xms4000M -Xmn600M -XX:PermSize=500M -XX:MaxPermSize=500M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log

CMSInitiatingOccupancyFraction值與Xmn的關(guān)系公式
上面介紹了promontion faild產(chǎn)生的原因是EDEN空間不足的情況下將EDEN與From survivor中的存活對(duì)象存入To survivor區(qū)時(shí),To survivor區(qū)的空間不足，再次晉升到old gen區(qū)，而old gen區(qū)內(nèi)存也不夠的情況下產(chǎn)生了promontion faild從而導(dǎo)致full gc.那可以推斷出：eden+from survivor < old gen區(qū)剩余內(nèi)存時(shí)，不會(huì)出現(xiàn)promontion faild的情況，即：
(Xmx-Xmn)*(1-CMSInitiatingOccupancyFraction/100)>=(Xmn-Xmn/(SurvivorRatior+2)) 進(jìn)而推斷出：
CMSInitiatingOccupancyFraction <=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)*100
例如：
當(dāng)xmx=128 xmn=36 SurvivorRatior=1時(shí) CMSInitiatingOccupancyFraction<=((128.0-36)-(36-36/(1+2)))/(128-36)*100 =73.913
當(dāng)xmx=128 xmn=24 SurvivorRatior=1時(shí) CMSInitiatingOccupancyFraction<=((128.0-24)-(24-24/(1+2)))/(128-24)*100=84.615…
當(dāng)xmx=3000 xmn=600 SurvivorRatior=1時(shí) CMSInitiatingOccupancyFraction<=((3000.0-600)-(600-600/(1+2)))/(3000-600)*100=83.33
CMSInitiatingOccupancyFraction低于70% 需要調(diào)整xmn或SurvivorRatior值。

總結(jié)

以上是生活随笔為你收集整理的72.JVM参数设置(各种jvm参数)、分析；Total Heap；The Young Generation；的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。