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

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

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

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

分析過程

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

?

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

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

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

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

到了6月份，情況卻變化很大，時間分別為 10.791% 和 8.417% ，因為超過了5%的警戒線而顯示為紅色，而且79%的GC時間花在full gc上。

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

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

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

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

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

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

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

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

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

優(yōu)化操作

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

調(diào)整方法 ：增大年輕代大小，減小SurvivorRatio加大Survivor區(qū)（也就是From or To）；設(shè)置并行回收參數(shù);設(shè)置初始堆和最大堆為同樣值、設(shè)置初始PermSize為一個合理值，避免運行過程中增長；設(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ū)做并行回收，也是一個遺憾）

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

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

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

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

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

其它的一些碎碎念

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

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

IBM JDK下避免主動回收的參數(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日志（一個實際案例的診斷過程）