<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    jinfeng_wang

    G-G-S,D-D-U!

    BlogJava 首頁 新隨筆 聯系 聚合 管理
      400 Posts :: 0 Stories :: 296 Comments :: 0 Trackbacks
    http://www.cjsdn.net/post/print?bid=62&id=196304


    JVM參數調優是一個很頭痛的問題,可能和應用有關系,下面是本人一些調優的實踐經驗,希望對讀者能有幫助,環境LinuxAS4,resin2.1.17,JDK6.0,2CPU,4G內存,dell2950服務器,網站是http://shedewang.com

    一:串行垃圾回收,也就是默認配置,完成10萬request用時153秒,JVM參數配置如下
    $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啟動24小時內似乎沒有大問題,網站可以正常訪問,但查看日志發現,在接近24小時時,Full GC執行越來越頻繁,大約每隔3分鐘就有一次Full GC,每次Full GC系統會停頓6秒左右,作為一個網站來說,用戶等待6秒恐怕太長了,所以這種方式有待改善。MaxTenuringThreshold=7表示一個對象如果在救助空間移動7次還沒有被回收就放入年老代,GCTimeRatio=19表示java可以用5%的時間來做垃圾回收,1/(1+19)=1 /20=5%。

    二:并行回收,完成10萬request用時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啟動3小時左右就會停頓,時間超過10 秒。也有可能是參數設置不夠好的原因,MaxGCPauseMillis表示GC最大停頓時間,在resin剛啟動還沒有執行Full GC時系統是正常的,但一旦執行Full GC,MaxGCPauseMillis根本沒有用,停頓時間可能超過20秒,之后會發生什么我也不再關心了,趕緊重啟resin,嘗試其他回收策略。

    三:并發回收,完成10萬request用時60秒,比并行回收差不多快一倍,是默認回收策略性能的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 ";
    這個配置雖然不會出現10秒連不上的情況,但系統重啟3個小時左右,每隔幾分鐘就會有5秒連不上的情況,查看gc.log,發現在執行ParNewGC時有個promotion failed錯誤,從而轉向執行Full GC,造成系統停頓,而且會很頻繁,每隔幾分鐘就有一次,所以還得改善。UseCMSCompactAtFullCollection是表是執行Full GC后對內存進行硌顧酰獾貌詿嫠櫧珻MSFullGCsBeforeCompaction=N表示執行N次Full GC后執行內存壓縮。

    四:增量回收,完成10萬request用時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 ";
    似乎回收得也不太干凈,而且也對性能有較大影響,不值得試。

    五:并發回收的I-CMS模式,和增量回收差不多,完成10萬request用時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推薦的參數,回收效果不好,照樣有停頓,數小時之內就會頻繁出現停頓,什么sun推薦的參數,照樣不好使。

    六:遞增式低暫停收集器,還叫什么火車式回收,不知道屬于哪個系,完成10萬request用時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 ";
    該配置效果也不好,影響性能,所以沒試。

    七:相比之下,還是并發回收比較好,性能比較高,只要能解決ParNewGC(并行回收年輕代)時的promotion failed錯誤就一切好辦了,查了很多文章,發現引起promotion failed錯誤的原因是CMS來不及回收(CMS默認在年老代占到90%左右才會執行),年老代又沒有足夠的空間供GC把一些活的對象從年輕代移到年老代,所以執行Full GC。CMSInitiatingOccupancyFraction=70表示年老代占到約70%時就開始執行CMS,這樣就不會出現Full GC了。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秒,所以設置成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 ";
    上面這個配置內存上升的很慢,24小時之內幾乎沒有停頓現象,最長的只停滯了0.8s,ParNew GC每30秒左右才執行一次,每次回收約0.2秒,看來問題應該暫時解決了。

    參數不明白的可以上網查,本人認為比較重要的幾個參數是:-Xms -Xmx -Xmn MaxTenuringThreshold GCTimeRatio UseConcMarkSweepGC CMSInitiatingOccupancyFraction SoftRefLRUPolicyMSPerMB
    posted on 2008-11-11 14:44 jinfeng_wang 閱讀(1496) 評論(1)  編輯  收藏 所屬分類: javaZZ

    評論

    # re: JVM參數調優實踐 xx 2011-11-24 11:15 蕭工
    您好!
    能請問下你的resin是怎么配置的嗎?本人現在在做resin的服務器集群發現很不穩定,基本上每天服務器都會奔潰,根據您上面的配置也做了優化但還是沒有明顯的效果。能幫我分析下是什么原因嗎?這是我的QQ號:306030016
    對resin比較熟悉的請聯系本人。謝謝  回復  更多評論
      

    主站蜘蛛池模板: 亚洲色爱图小说专区| 日本亚洲欧美色视频在线播放| 最近的免费中文字幕视频| 美女被爆羞羞网站在免费观看| 亚洲第一精品福利| 亚洲AV无码成人网站久久精品大| 午夜a级成人免费毛片| 国产一精品一AV一免费| 国产成人人综合亚洲欧美丁香花| 亚洲美女大bbbbbbbbb| 久久青青草原亚洲av无码app | 亚洲AV无码专区在线电影成人| 亚洲AV天天做在线观看| 日韩亚洲Av人人夜夜澡人人爽| 亚洲av无码乱码在线观看野外| 无遮免费网站在线入口| 国偷自产一区二区免费视频| 国产成人无码区免费内射一片色欲| 美女的胸又黄又www网站免费| 精品日韩99亚洲的在线发布| 亚洲综合av一区二区三区不卡| 亚洲人成网站影音先锋播放| 亚洲精品国产肉丝袜久久| 亚洲国产成人久久99精品| 亚洲AV日韩AV鸥美在线观看| 亚洲欧洲另类春色校园小说| 亚洲一区二区三区国产精华液| 日产亚洲一区二区三区| 亚洲国产精品嫩草影院在线观看| 亚洲免费在线观看| 成人国产mv免费视频| 亚洲一区二区三区国产精品| 国产精品视频免费一区二区三区| 中文字幕人成无码免费视频| 国产成人精品免费视| 四虎成人精品永久免费AV| 日韩精品无码免费专区网站| xxxxx做受大片视频免费| 黄网站色视频免费在线观看的a站最新 | 大学生a级毛片免费观看| 国产在线观看麻豆91精品免费|