http://www.cjsdn.net/post/print?bid=62&id=196304
JVM參數(shù)調(diào)優(yōu)是一個(gè)很頭痛的問題，可能和應(yīng)用有關(guān)系，下面是本人一些調(diào)優(yōu)的實(shí)踐經(jīng)驗(yàn)，希望對讀者能有幫助，環(huán)境LinuxAS4,resin2.1.17,JDK6.0,2CPU,4G內(nèi)存,dell2950服務(wù)器，網(wǎng)站是http://shedewang.com
一：串行垃圾回收，也就是默認(rèn)配置，完成10萬request用時(shí)153秒，JVM參數(shù)配置如下
$JAVA_ARGS .= " -Dresin.home=$SERVER_ROOT -server -Xms2048M -Xmx2048M -Xmn512M -XX:PermSize=256M -XX:MaxPermSize=256M -XX:MaxTenuringThreshold=7 -XX:GCTimeRatio=19 -Xnoclassgc -Xloggc:log/gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps ";
這種配置一般在resin啟動(dòng)24小時(shí)內(nèi)似乎沒有大問題，網(wǎng)站可以正常訪問，但查看日志發(fā)現(xiàn)，在接近24小時(shí)時(shí)，F(xiàn)ull GC執(zhí)行越來越頻繁，大約每隔3分鐘就有一次Full GC，每次Full GC系統(tǒng)會(huì)停頓6秒左右，作為一個(gè)網(wǎng)站來說，用戶等待6秒恐怕太長了，所以這種方式有待改善。MaxTenuringThreshold=7表示一個(gè)對象如果在救助空間移動(dòng)7次還沒有被回收就放入年老代，GCTimeRatio=19表示java可以用5%的時(shí)間來做垃圾回收，1/(1+19)=1 /20=5%。
二：并行回收，完成10萬request用時(shí)117秒，配置如下：
$JAVA_ARGS .= " -Dresin.home=$SERVER_ROOT -server -Xmx2048M -Xms2048M -Xmn512M -XX:PermSize=256M -XX:MaxPermSize=256M -Xnoclassgc -Xloggc:log/gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC -XX:MaxGCPauseMillis=500 -XX:+UseAdaptiveSizePolicy -XX:MaxTenuringThreshold=7 -XX:GCTimeRatio=19 ";
并行回收我嘗試過多種組合配置，似乎都沒什么用，resin啟動(dòng)3小時(shí)左右就會(huì)停頓，時(shí)間超過10 秒。也有可能是參數(shù)設(shè)置不夠好的原因，MaxGCPauseMillis表示GC最大停頓時(shí)間，在resin剛啟動(dòng)還沒有執(zhí)行Full GC時(shí)系統(tǒng)是正常的，但一旦執(zhí)行Full GC，MaxGCPauseMillis根本沒有用，停頓時(shí)間可能超過20秒，之后會(huì)發(fā)生什么我也不再關(guān)心了，趕緊重啟resin，嘗試其他回收策略。
三：并發(fā)回收，完成10萬request用時(shí)60秒，比并行回收差不多快一倍，是默認(rèn)回收策略性能的2.5倍，配置如下：
$JAVA_ARGS .= " -Dresin.home=$SERVER_ROOT -server -Xms2048M -Xmx2048M -Xmn512M -XX:PermSize=256M -XX:MaxPermSize=256M -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=7 -XX:GCTimeRatio=19 -Xnoclassgc -Xloggc:log/gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 ";
這個(gè)配置雖然不會(huì)出現(xiàn)10秒連不上的情況，但系統(tǒng)重啟3個(gè)小時(shí)左右，每隔幾分鐘就會(huì)有5秒連不上的情況，查看gc.log，發(fā)現(xiàn)在執(zhí)行ParNewGC時(shí)有個(gè)promotion failed錯(cuò)誤，從而轉(zhuǎn)向執(zhí)行Full GC，造成系統(tǒng)停頓，而且會(huì)很頻繁，每隔幾分鐘就有一次，所以還得改善。UseCMSCompactAtFullCollection是表是執(zhí)行Full GC后對內(nèi)存進(jìn)行硌顧酰獾貌詿嫠櫧珻MSFullGCsBeforeCompaction=N表示執(zhí)行N次Full GC后執(zhí)行內(nèi)存壓縮。
四：增量回收，完成10萬request用時(shí)171秒，太慢了，配置如下
$JAVA_ARGS .= " -Dresin.home=$SERVER_ROOT -server -Xms2048M -Xmx2048M -Xmn512M -XX:PermSize=256M -XX:MaxPermSize=256M -XX:MaxTenuringThreshold=7 -XX:GCTimeRatio=19 -Xnoclassgc -Xloggc:log/gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xincgc ";
似乎回收得也不太干凈，而且也對性能有較大影響，不值得試。
五：并發(fā)回收的I-CMS模式，和增量回收差不多，完成10萬request用時(shí)170秒。
$JAVA_ARGS .= " -Dresin.home=$SERVER_ROOT -server -Xms2048M -Xmx2048M -Xmn512M -XX:PermSize=256M -XX:MaxPermSize=256M -XX:MaxTenuringThreshold=7 -XX:GCTimeRatio=19 -Xnoclassgc -Xloggc:log/gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:CMSIncrementalDutyCycle=10 -XX:-TraceClassUnloading ";
采用了sun推薦的參數(shù)，回收效果不好，照樣有停頓，數(shù)小時(shí)之內(nèi)就會(huì)頻繁出現(xiàn)停頓，什么sun推薦的參數(shù)，照樣不好使。
六：遞增式低暫停收集器，還叫什么火車式回收，不知道屬于哪個(gè)系，完成10萬request用時(shí)153秒
$JAVA_ARGS .= " -Dresin.home=$SERVER_ROOT -server -Xms2048M -Xmx2048M -Xmn512M -XX:PermSize=256M -XX:MaxPermSize=256M -XX:MaxTenuringThreshold=7 -XX:GCTimeRatio=19 -Xnoclassgc -Xloggc:log/gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseTrainGC ";
該配置效果也不好，影響性能，所以沒試。
七：相比之下，還是并發(fā)回收比較好，性能比較高，只要能解決ParNewGC（并行回收年輕代）時(shí)的promotion failed錯(cuò)誤就一切好辦了，查了很多文章，發(fā)現(xiàn)引起promotion failed錯(cuò)誤的原因是CMS來不及回收（CMS默認(rèn)在年老代占到90%左右才會(huì)執(zhí)行），年老代又沒有足夠的空間供GC把一些活的對象從年輕代移到年老代，所以執(zhí)行Full GC。CMSInitiatingOccupancyFraction=70表示年老代占到約70%時(shí)就開始執(zhí)行CMS，這樣就不會(huì)出現(xiàn)Full GC了。SoftRefLRUPolicyMSPerMB這個(gè)參數(shù)也是我認(rèn)為比較有用的，官方解釋是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秒，所以設(shè)置成0。配置如下
$JAVA_ARGS .= " -Dresin.home=$SERVER_ROOT -server -Xms2048M -Xmx2048M -Xmn512M -XX:PermSize=256M -XX:MaxPermSize=256M -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=7 -XX:GCTimeRatio=19 -Xnoclassgc -XX:+DisableExplicitGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:-CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=70 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime -Xloggc:log/gc.log ";
上面這個(gè)配置內(nèi)存上升的很慢，24小時(shí)之內(nèi)幾乎沒有停頓現(xiàn)象，最長的只停滯了0.8s，ParNew GC每30秒左右才執(zhí)行一次，每次回收約0.2秒，看來問題應(yīng)該暫時(shí)解決了。
參數(shù)不明白的可以上網(wǎng)查，本人認(rèn)為比較重要的幾個(gè)參數(shù)是：-Xms -Xmx -Xmn MaxTenuringThreshold GCTimeRatio UseConcMarkSweepGC CMSInitiatingOccupancyFraction SoftRefLRUPolicyMSPerMB