首頁  >  文章  >  Java  >  JVM參數調優實例解析

JVM參數調優實例解析

巴扎黑
巴扎黑原創
2017-06-27 09:19:481262瀏覽

原文出處:

 

關於JVM參數調優,對於許多程式設計師來說都是很頭痛的問題,如果設定的不好,JVM不斷執行Full GC,將導致整個系統變得很慢,網站停滯時間能達10秒以上,這種情況如果沒隔幾分鐘就來一次,自己都受不了。

這種停滯在測試的時候看不出來,只有網站pv達到數十萬/天的時候問題就暴露出來了,要想配置好JVM參數,需要對年輕代、年老代、救助空間和永久代有一定了解,還要了解JVM記憶體管理邏輯,最終還要根據自己的應用來做調整。關於JVM參數上網一搜就能搜出一大把,也有很多提供實踐的例子,我也按照各種例子測試過,最終還是會出現問題,經過幾個月的實踐改善,我就網站(要求無停滯時間)的jvm參數調優給出以下幾個經驗。

1:建議用64位元作業系統,Linux下64位元的JDK比32位元JDK慢一些,但是吃得記憶體更多,吞吐量更大。

2:XMX和XMS設定一樣大,MaxPermSize和MinPermSize設定一樣大,這樣可以減輕伸縮堆大小帶來的壓力。

3:偵錯的時候設定一些列印參數,例如-XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log,這樣可以從gc .log裡看出一些端倪出來。

4:系統停頓的時候可能是GC的問題也可能是程式的問題,多用Jmap和Jstack查看,或者killall -3 Java,然後查看Java控制台日誌,能看出很多問題。有一次,網站突然很慢,Jstack一看,原來是自己寫的URL Connection連線太多沒釋放,改一下程式就OK了。

5:仔細了解自己的應用,如果用了緩存,那麼年老代應該大一些,緩存的HashMap不應該無限制長,建議採用LRU演算法的Map做緩存,LRUMap的最大長度也要根據實際情況設定。

6:垃圾回收時Promotion Failed是個很頭痛的問題,一般可能是兩種原因產生,第一個原因是救助空間不夠,救助空間裡的對象還不應該被移動到年老代,但年輕代又有很多對象需要放入救助空間;第二個原因是年老代沒有足夠的空間接納來自年輕代的對象;這兩種情況都會轉向Full GC,網站停頓時間較長。第一個原因我的最終解決方法是去掉救助空間,設定-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0即可,第二個原因我的解決方法是設定CMSInitiatingOccupancyFraction為某個值(假設70),這樣年老代空間到70%時就開始執行CMS,年老代有足夠的空間接納來自年輕代的對象。

7:不管怎樣,永久代還是會逐漸變滿,所以隔三差五重起Java伺服器是必要的,我每天都自動重起。

8:採用並發回收時,年輕代小一點,年老代要大,因為年老大用的是並發回收,即使時間長點也不會影響其他程序繼續運行,網站不會停頓,我的最終配置如下(系統8G記憶體),每天幾百萬PV一點問題都沒有,網站沒有停頓,2009年網站沒有因為記憶體問題down過機。

  1. $JAVA_ARGS .= " -Dresin.home=$SERVER_ROOT -server -Xms6000M -Xmx6000M-Xmn500M5:00Mmn

  2. -XX:MaxPermSize=500M -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0 -Xnoclassgc -XX:+DisableExplicitGC   

  3. ##-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XXAt:+Use

  4. -XX:CMSFullGCsBeforeCompaction=

    0 -XX:+CMSClassUnloadingEnabled -XX:-CMSParallelRemarkEnabled   

  5. -XX:CMSInitiatingOccupancyFraction=

    90 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram   

  6. -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log ";  

##說明一下,-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0就是去掉了救援空間:


#◆ -Xnoclassgc停用類別垃圾回收,效能會高一點; 
◆-XX:+DisableExplicitGC禁止System.gc(),免得程式設計師誤呼叫gc方法影響效能; 
◆-XX:+UseParNewGC,對年輕代採用多執行緒並行回收,這樣收得快;有CMS參數的都是和並發回收相關的。

CMSInitiatingOccupancyFraction#

這個參數設定有很大技巧,基本上滿足(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn#就不會出現promotion failed。在我的應用中Xmx是6000,Xmn是500,那麼Xmx-Xmn是5500兆,也就是年老代有5500兆,CMSInitiatingOccupancyFraction=90說明年老代到90%滿的時候開始執行對年老代的併發垃圾回收(CMS),這時還剩10%的空間是5500*10%=550兆,所以即使Xmn(也就是年輕代共500兆)裡所有對像都搬到年老代裡,550兆的空間也足夠了,所以只要滿足上面的公式,就不會出現垃圾回收時的Promotion Failed;

SoftRefLRUPolicyMSPerMB

##這個參數我認為可能有點用,官方解釋是softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap,我覺得沒必要等1秒;

# #網上其他介紹JVM參數的也比較多,估計其中大部分是沒有遇到Promotion Failed,或者訪問量太小沒有機會遇到,(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn這個公式絕對是原創,真遇到Promotion Failed了,還得這麼處理。

以上是JVM參數調優實例解析的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn