HPjmeter集成了以前的HPjtune功能，可以分析在HP機(jī)器上產(chǎn)生的垃圾回收日志文件。你可以到 Hewlett-Packard Java website 免費(fèi)下載最新的4.0版本，當(dāng)然會(huì)讓你填一些信息。

接下來我將分析一個(gè)實(shí)際生產(chǎn)環(huán)境下的日志文件，這個(gè)生產(chǎn)系統(tǒng)在啟用新的功能后應(yīng)用訪問速度變慢，每個(gè)操作都要耗時(shí)10s左右，通過對(duì)比前后不同的gc信息，希望能從JVM的層面來優(yōu)化當(dāng)前的性能。

HP小機(jī)（Pa-Risc和安騰平臺(tái)）使用HP的JDK后，使用-Xloggc:filename或者-Xverbosegc:file=filename參數(shù)會(huì)生成形如

的日志，這種格式人肉分析就別想了，它可以在PMAT中以Xverbosegc/hpux文件格式打開，但是圖象功能我這里沒法使用，只好求助于HP自家的工具——HPjmeter了。

分析過程

用HPjmeter加載日志文件后，會(huì)自動(dòng)打開HPjtune的窗口。首先會(huì)看到Heap Usage After GC標(biāo)簽頁，這是四月份正常的情況（請(qǐng)先忽略systemgc，這點(diǎn)留待后面分析）

?

下面是六月份速度慢的情況：

明顯能看到Old full（with perm）代表的黃點(diǎn)增多了，從之前的日志文件頭我們了解到這個(gè)系統(tǒng)所用的 JDK為1.4.2 32位版本（64位版本會(huì)寫明Java VM name = Java HotSpot(TM) 64-Bit Server VM） ，默認(rèn)的回收策略是串行收集器，在Old區(qū)發(fā)生垃圾回收時(shí)是Stop the world的full gc，每次full gc耗時(shí)基本在10s～12s

切換到”Summary”標(biāo)簽頁

4月花在gc上的時(shí)間占整個(gè)JVM運(yùn)行時(shí)間的3.036%，F(xiàn)ull GC占整個(gè)JVM運(yùn)行時(shí)間的0.993%，應(yīng)該說是情況良好。

到了6月份，情況卻變化很大，時(shí)間分別為 10.791% 和 8.417% ，因?yàn)槌^了5%的警戒線而顯示為紅色，而且79%的GC時(shí)間花在full gc上。

這還是一周的情況，包括了周末和晚間空閑時(shí)刻，讓我們看看在上班高峰期間的運(yùn)行情況。

乖乖，有61%的時(shí)間花在gc上，速度不慢才怪了。我們查看當(dāng)前對(duì)應(yīng)的Heap Usage After GC

除了開始的少數(shù)年輕代中發(fā)生的快速Scavenge，大部分都是慢速的Full GC，而且可以看到每次回收后使用的堆空間并沒有減小，反而越來越大，有內(nèi)存泄漏的征兆。不過堆空間并沒有一路增長下去直到OutOfMemory，而是像下圖般那樣反復(fù)。

早上和下午兩個(gè)業(yè)務(wù)繁忙期全是full gc，性能表現(xiàn)很差，而4月正常的情況應(yīng)是如此

Eden區(qū)滿了后，經(jīng)過Scavenge動(dòng)作一部分對(duì)象被轉(zhuǎn)移到了Old區(qū)，所以堆中占用空 間上升，直到Old區(qū)也無法分配了，那么發(fā)生full gc，內(nèi)存又重新回到一個(gè)較低的位置，這是正常的情況。現(xiàn)在6月份出現(xiàn)一直Full GC也無法回收，但又沒有發(fā)生OutOfMemory，可以判斷為原來設(shè)置的參數(shù)無法滿足新內(nèi)容投產(chǎn)后的需求

例如沒有使用并行回收，沒有發(fā)揮8個(gè)CPU的效果，沒有采用低響應(yīng)時(shí)間的CMS回收模式。

同時(shí)新系統(tǒng)產(chǎn)生的對(duì)象數(shù)量也大大增加，從四月一天的500000個(gè)增加到900000個(gè)（左邊四月，右邊六月）。

導(dǎo)致每次回收后，從新生代轉(zhuǎn)移到年老區(qū)的對(duì)象數(shù)量也變多，其實(shí)它們并非是長存對(duì)象，只是新生代暫時(shí)無法容納下它們了。

而且full gc會(huì)導(dǎo)致Survivor區(qū)里的所有對(duì)象都被轉(zhuǎn)移到old區(qū)，這造成了惡性循環(huán)。（黃色的Full GC后，Survivor里的對(duì)象為零）

優(yōu)化操作

調(diào)整目標(biāo) ：盡可能的將短時(shí)間存活的對(duì)象在年輕代就能被丟棄掉，而不要轉(zhuǎn)移到年老代中；采用并行回收方式增加效率；避免產(chǎn)生不必要的Full GC；或者采用響應(yīng)時(shí)間短的垃圾回收方式。

調(diào)整方法 ：增大年輕代大小，減小SurvivorRatio加大Survivor區(qū)（也就是From or To）；設(shè)置并行回收參數(shù);設(shè)置初始堆和最大堆為同樣值、設(shè)置初始PermSize為一個(gè)合理值，避免運(yùn)行過程中增長；設(shè)置回收策略為CMS。

參數(shù)設(shè)置一 ：-Xms1500m -Xmx1500m -Xmn800m -XX:SurvivorRatio=4 -XX:PermSize=160m? -XX:+UseParallelGC（-XX:ParallelGCThreads=8我覺得可以不用顯示的聲明，可以再上述參數(shù)設(shè)置后分析新的gc log，看一下System Details頁面中ParallelGCThreads的數(shù)目再做定奪，1.4.2的JDK不能再Old區(qū)做并行回收，也是一個(gè)遺憾）

參數(shù)設(shè)置二 ：-Xms1500m -Xmx1500m -Xmn800m -XX:PermSize=160m? -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSFullGCsBeforeCompaction=5（或者最后一個(gè)參數(shù)設(shè)置為 -XX:+UseCMSCompactAtFullCollection）

上述參數(shù)的意義可以看 《JAVA性能優(yōu)化—Sun Hotspot JDK JVM參數(shù)設(shè)置》

后續(xù)進(jìn)展

參數(shù)設(shè)置后還有一個(gè)觀察過程，如果效果不佳，那從系統(tǒng)集成的角度，一是更換64位JDK，這 樣可以設(shè)置更大的堆空間（不過WebSphere更換JDK不像Weblogic那么簡單，如果沒有買過64位WebSphere的話只好作罷）；二是啟 用WebSphere的集群，但這需要ND版本的WAS。

從應(yīng)用的角度，可以在早上8點(diǎn)做一次heapdump，9點(diǎn)半做一次heapdump，分析 一下full gc內(nèi)存回收不下來的原因，確定不是程序的錯(cuò)誤造成的。或者啟用-agentlib:hprof參數(shù)，用HPjmeter來trace應(yīng)用的表現(xiàn)、用 HPjmeter來直接監(jiān)控應(yīng)用的運(yùn)行情況。不過這兩個(gè)方法對(duì)性能影響較大，要在測(cè)試環(huán)境下進(jìn)行。

其它的一些碎碎念

現(xiàn)在我們來說說日志中那么多的systemgc，剛開始看到我大吃一驚，但放大圖像后發(fā)現(xiàn)這些自行調(diào)用的full gc都是下班后做的，應(yīng)該是另一個(gè)應(yīng)用觸發(fā)的，對(duì)白天的性能影響應(yīng)該不大。

不過這里還是要再申明一句：自行調(diào)用System.gc（）函數(shù)會(huì)損害到JVM的性能，因?yàn)?這時(shí)候是Stop the World的回收，消耗的時(shí)間長，但效果并非最佳。你也許會(huì)認(rèn)為你對(duì)程序很熟悉，可以在空閑的時(shí)間執(zhí)行system.gc，不會(huì)影響到客戶訪問，但是正如 之前所說，full gc后survivor里的所有內(nèi)容都被轉(zhuǎn)移到了old區(qū)長久保存，所以在某個(gè)將來，JVM就不得不因?yàn)檫@個(gè)原因再做一次不必要的full gc。

IBM JDK下避免主動(dòng)回收的參數(shù)是“ -Xdisableexplicitgc ”，Sun JDK下的參數(shù)是“ -XX:+DisableExplicitGC ”，注意區(qū)別。

?

?

轉(zhuǎn)載 http://www.hashei.me/2009/07/use-hpjtune-to-analysis-gc-log.html

用HPjtune分析GC日志（一個(gè)實(shí)際案例的診斷過程）