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

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

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

    放翁(文初)的一畝三分地

      BlogJava :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
      210 隨筆 :: 1 文章 :: 320 評(píng)論 :: 0 Trackbacks

           SIP5.0以后服務(wù)的請求量爆發(fā)性增長,因此也暴露了原來沒有暴露出來的問題。由于過去一般一個(gè)新版本發(fā)布周期在一個(gè)月左右,因此如果是小的內(nèi)存泄露,在一個(gè)月之內(nèi)重新發(fā)布以后也就看不出任何問題。

    因此這陣子除了優(yōu)化Memcache客戶端和SIP框架邏輯以外其他依賴部分以外,對于內(nèi)存泄露的壓力測試也開始實(shí)實(shí)在在的做起來。經(jīng)過這次問題的定位和解決以后,大致覺得對于一個(gè)大用戶量應(yīng)用要放心的話,那么需要做這么幾步。

    1.       GC輸出的環(huán)境下,大壓力下做多天的測試。(可以在 JAVA_OPTS增加-verbose:gc -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError

    2.       檢查GC輸出日志來判斷是否有內(nèi)存泄露。(這部分后面有詳細(xì)的實(shí)例說明)

    3.       如果出現(xiàn)內(nèi)存泄露問題,則使用jprofiler等工具來排查內(nèi)存泄露點(diǎn)(之所以不一開始使用,因?yàn)?/span>jprofiler等工具對于壓力測試有影響,使得大壓力無法上去,也使問題不那么容易暴露)

    4.       解決問題,并在重復(fù)2步驟。

    這里對SIPjdk1.5jdk1.6下做壓力測試的GC 日志來做一個(gè)實(shí)際的分析對比,通過對比來大致描述一下如何根據(jù)輸出情況能夠了解應(yīng)用是否存在內(nèi)存泄露問題。(這里的內(nèi)存泄露問題就是在以前blog寫過的jdkconcurrent包內(nèi)LinkedBlockingQueuepoll方法存在比較嚴(yán)重的內(nèi)存泄露,調(diào)用頻率越高,內(nèi)存泄露的越厲害)

    兩次壓力測試都差不多都是兩天,測試方案如下:

    開始50個(gè)并發(fā),每個(gè)并發(fā)每次請求完畢后休息0.1秒,10分鐘后增長50個(gè)并發(fā),按此規(guī)律增長到500并發(fā)。

    舊版本SIP是在JDK1.5環(huán)境下完成的壓力測試,

    新版本SIPJDK版本是1.6

    壓力機(jī)和以前一樣,是10.2.226.40DELL19508CPU8G內(nèi)存。

    壓力機(jī)模擬發(fā)出對一個(gè)需要簽名的API不斷的調(diào)用請求。

    看看兩個(gè)Log的具體內(nèi)容(內(nèi)容很多截取部分做分析)

    先說一下日志輸出的結(jié)構(gòu):(1.61.5略微有一些不同,只是1.6對于時(shí)間統(tǒng)計(jì)更加細(xì)致)

    [GC [<collector>: <starting occupancy1> -> <ending occupancy1>, <pause time1> secs] <starting occupancy3> -> <ending occupancy3>, <pause time3> secs]

    <collector>GC收集器的名稱

    <starting occupancy1> 新生代在GC前占用的內(nèi)存

    <ending occupancy1> 新生代在GC后占用的內(nèi)存

    <pause time1> 新生代局部收集時(shí)jvm暫停處理的時(shí)間

    <starting occupancy3> JVM Heap GC前占用的內(nèi)存

    <ending occupancy3> JVM Heap GC后占用的內(nèi)存

    <pause time3> GC過程中jvm暫停處理的總時(shí)間

    Jdk1.5 log

    啟動(dòng)時(shí)GC輸出:

    [GC [DefNew: 209792K->4417K(235968K), 0.0201630 secs] 246722K->41347K(498112K), 0.0204050 secs]

    [GC [DefNew: 214209K->4381K(235968K), 0.0139200 secs] 251139K->41312K(498112K), 0.0141190 secs]

    一句輸出:

    新生代回收前209792K,回收后4417K,回收數(shù)量205375KHeap總量回收前246722K回收后41347K,回收總量205375K。這就表示100%的收回,沒有任何新生代的對象被提升到中生代或者永久區(qū)(名字說的不一定準(zhǔn)確,只是表達(dá)意思)。

    第二句輸出:

    按照分析也就只是有1K內(nèi)容被提升到中生代。

    運(yùn)行一段時(shí)間后:

    [GC [DefNew: 210686K->979K(235968K), 0.0257140 secs] 278070K->68379K(498244K), 0.0261820 secs]

    [GC [DefNew: 210771K->1129K(235968K), 0.0275160 secs] 278171K->68544K(498244K), 0.0280050 secs]

    第一句輸出:

             新生代回收前210686K,回收后979K,回收數(shù)量209707KHeap總量回收前278070K回收后68379K,回收總量209691K。這就表示有16k沒有被回收。

    第二句輸出:

             新生代回收前210771K,回收后1129K,回收數(shù)量209642KHeap總量回收前278171K回收后68544K,回收總量209627K。這就表示有15k沒有被回收。

    比較一下啟動(dòng)時(shí)與現(xiàn)在的新生代占用內(nèi)存情況和Heap使用情況發(fā)現(xiàn)Heap的使用增長很明顯,新生代沒有增長,而Heap使用總量增長了27M,這就表明可能存在內(nèi)存泄露,雖然每一次泄露的字節(jié)數(shù)很少,但是頻率很高,大部分泄露的對象都被升級(jí)到了中生代或者持久代。

    又一段時(shí)間后:

    [GC [DefNew: 211554K->1913K(235968K), 0.0461130 secs] 350102K->140481K(648160K), 0.0469790 secs]

    [GC [DefNew: 211707K->2327K(235968K), 0.0546170 secs] 350275K->140921K(648160K), 0.0555070 secs]

    第一句輸出:

             新生代回收前211554K,回收后1913K,回收數(shù)量209641KHeap總量回收前350102K回收后140481K,回收總量209621K。這就表示有20k沒有被回收。

             分析到這里就可以看出每一次泄露的內(nèi)存只有10K,但是在大壓力長時(shí)間的測試下,內(nèi)存泄露還是很明顯的,此時(shí)Heap已經(jīng)增長到了140M,較啟動(dòng)時(shí)已經(jīng)增長了100M。同時(shí)GC占用的時(shí)間越來越長。

    后續(xù)的現(xiàn)象:

             后續(xù)觀察日志會(huì)發(fā)現(xiàn),Full GC的頻率越來越高,收集所花費(fèi)時(shí)間也是越來越長。(Full GC定期會(huì)執(zhí)行,同時(shí)局部回收不能滿足分配需求的情況下也會(huì)執(zhí)行)。

    [Full GC [Tenured: 786431K->786431K(786432K), 3.4882390 secs] 1022399K->1022399K(1022400K), [Perm : 36711K->36711K(98304K)], 3.4887920 secs]

    java.lang.OutOfMemoryError: Java heap space

    Dumping heap to java_pid7720.hprof ...

             出現(xiàn)這個(gè)語句表示內(nèi)存真的被消耗完了。

    Jdk1.6 log

     

    啟動(dòng)時(shí)GC的輸出:

    [GC [PSYoungGen: 221697K->31960K(229376K)] 225788K->36051K(491520K), 0.0521830 secs] [Times: user=0.26 sys=0.05, real=0.05 secs]

    [GC [PSYoungGen: 228568K->32752K(229376K)] 232659K->37036K(491520K), 0.0408620 secs] [Times: user=0.21 sys=0.02, real=0.04 secs]

    第一句輸出:

             新生代回收前221697K,回收后31960K,回收數(shù)量189737KHeap總量回收前225788K回收后36051K,回收總量189737K100%被回收。

    運(yùn)行一段時(shí)間后輸出:

    [GC [PSYoungGen: 258944K->2536K(259328K)] 853863K->598135K(997888K), 0.0471620 secs] [Times: user=0.15 sys=0.00, real=0.05 secs]

    [GC [PSYoungGen: 259048K->2624K(259328K)] 854647K->598907K(997888K), 0.0462980 secs] [Times: user=0.16 sys=0.02, real=0.04 secs]

    第一句輸出:

             新生代回收前258944K,回收后2536K,回收數(shù)量256408KHeap總量回收前853863K回收后598135K,回收總量255728K680K沒有被回收,但這并不意味著就會(huì)產(chǎn)生內(nèi)存泄露。同時(shí)可以看出GC回收時(shí)間并沒有增加。

    在運(yùn)行一段時(shí)間后輸出:

    [GC [PSYoungGen: 258904K->2488K(259264K)] 969663K->713923K(1045696K), 0.0485140 secs] [Times: user=0.16 sys=0.01, real=0.04 secs]

    [GC [PSYoungGen: 258872K->2448K(259328K)] 970307K->714563K(1045760K), 0.0473770 secs] [Times: user=0.16 sys=0.01, real=0.05 secs]

    第一句輸出:

             新生代回收前258904K,回收后2488K,回收數(shù)量256416KHeap總量回收前969663K回收后713923K,回收總量255740K676K沒有被回收,同時(shí)總的Heap也有所增加。

             此時(shí)看起來好像和1.5的狀況一樣。但是查看了一下Full GC的執(zhí)行還是400-500GC執(zhí)行一次,因此繼續(xù)觀察。

    運(yùn)行一天多以后輸出:

    [GC [PSYoungGen: 257016K->3304K(257984K)] 1019358K->766310K(1044416K), 0.0567120 secs] [Times: user=0.18 sys=0.01, real=0.06 secs]

    [GC [PSYoungGen: 257128K->2920K(258112K)] 1020134K->766622K(1044544K), 0.0549570 secs] [Times: user=0.19 sys=0.00, real=0.05 secs]

    可以發(fā)現(xiàn)Heap增長趨緩。

    運(yùn)行兩天以后輸出:

    [GC [PSYoungGen: 256936K->3584K(257792K)] 859561K->606969K(1044224K), 0.0565910 secs] [Times: user=0.18 sys=0.01, real=0.06 secs]

    [GC [PSYoungGen: 256960K->3368K(257728K)] 860345K->607445K(1044160K), 0.0553780 secs] [Times: user=0.18 sys=0.01, real=0.06 secs]

    發(fā)現(xiàn)Heap反而減少了,此時(shí)可以對內(nèi)存泄露問題作初步排除了。(其實(shí)在jdk1.6環(huán)境下用jprofiler來觀察,對于concurrent那個(gè)內(nèi)存泄露點(diǎn)的跟蹤發(fā)現(xiàn),內(nèi)存的確還是會(huì)不斷增長的,不過在一段時(shí)間后還是有回收,因此也就可以部分解釋前面出現(xiàn)的情況)

    總結(jié):

             對于GC輸出的觀察需要分兩個(gè)維度來看。一個(gè)是縱向比較,也就是一次回收對于內(nèi)存變化的觀察。一個(gè)是橫向比較,對于長時(shí)間內(nèi)存分配占用情況的比較,這部分比較需要較長時(shí)間的觀察,不能僅僅憑短時(shí)間的幾個(gè)抽樣比較,因?yàn)閷τ诔闃觼碚f,Full GC前后的區(qū)別,運(yùn)行時(shí)長的區(qū)別,資源瞬時(shí)占用的區(qū)別都會(huì)影響判斷。同時(shí)要結(jié)合Full GC發(fā)生的時(shí)間周期,每一次GC收集所耗費(fèi)的時(shí)間作為輔助判斷標(biāo)準(zhǔn)。

             順便說一下,Heap YoungGen,OldGen,PermGen的設(shè)置也是需要注意的,并不是越大越好,越大執(zhí)行收集的時(shí)間越久,但是可能執(zhí)行Full GC的頻率會(huì)比較低,因此需要權(quán)衡。這些仔細(xì)的去了解一下GC的基礎(chǔ)設(shè)計(jì)思想會(huì)更有幫助,不過一般用默認(rèn)的也不錯(cuò)。還有就是可以配置一些特殊的GC,并行,同步等等,充分利用多CPU的資源。

             對于GC的優(yōu)化可以通過現(xiàn)在很多圖形工具來做,也可以類似于我這樣采用最原始的分析方式,好處就是任何時(shí)間任何地點(diǎn)只要知道原理就可以分析無需借助外部工具。原始的總是最好的^_^

    posted on 2008-10-22 16:36 岑文初 閱讀(4843) 評(píng)論(5)  編輯  收藏

    評(píng)論

    # re: 通過GC輸出分析內(nèi)存泄露問題 2008-10-22 20:38 楊愛友
    高人,俺們寫代碼,只管功能實(shí)現(xiàn),絕對不考慮占用空間,極少考慮執(zhí)行效率,學(xué)習(xí)啊...  回復(fù)  更多評(píng)論
      

    # re: 通過GC輸出分析內(nèi)存泄露問題 2008-10-23 14:55 Always BaNg.
    你是淘寶的岑文初嗎?  回復(fù)  更多評(píng)論
      

    # re: 通過GC輸出分析內(nèi)存泄露問題 2008-10-23 15:05 岑文初
    @Always BaNg.
    不是淘寶,是阿里軟件
      回復(fù)  更多評(píng)論
      

    # re: 通過GC輸出分析內(nèi)存泄露問題 2014-07-04 18:46 dfdf
    sss  回復(fù)  更多評(píng)論
      

    # re: 通過GC輸出分析內(nèi)存泄露問題 2014-07-04 18:47 dfdf
    dfddddfffffffffffffffffffffff  回復(fù)  更多評(píng)論
      


    只有注冊用戶登錄后才能發(fā)表評(píng)論。


    網(wǎng)站導(dǎo)航:
     
    主站蜘蛛池模板: 国产福利在线观看永久免费| 国色精品卡一卡2卡3卡4卡免费| 免费人成在线观看视频高潮| 亚洲成色在线综合网站 | 亚洲av日韩综合一区在线观看| 亚洲精品无AMM毛片| 中文字幕亚洲综合久久男男| 中文字幕视频免费| 激情婷婷成人亚洲综合| 亚洲av网址在线观看| 国产免费拔擦拔擦8x| 老汉精品免费AV在线播放| 97久久国产亚洲精品超碰热| 国产亚洲AV手机在线观看| 四虎国产精品免费久久| 视频免费在线观看| 亚洲欧美不卡高清在线| 亚洲欧洲国产精品你懂的| 国产美女无遮挡免费视频| 四虎国产精品永久免费网址| 国产精品亚洲小说专区| 亚洲国产精品美女| 亚洲无线观看国产精品| 国产精品高清全国免费观看| 97公开免费视频| 日日狠狠久久偷偷色综合免费| 相泽亚洲一区中文字幕| 精品久久免费视频| 黄色成人免费网站| 日本人成在线视频免费播放| 性色av免费观看| 久热免费在线视频| 日韩电影免费在线观看网址| 亚洲首页国产精品丝袜| 亚洲爱情岛论坛永久| 亚洲色大成网站www永久一区| 无码人妻久久一区二区三区免费| 亚洲色偷偷av男人的天堂| 337p日本欧洲亚洲大胆裸体艺术| 最近免费mv在线电影| 99视频在线观看免费|