聚沙成塔-小哈的记事薄 » gc performance tuning

用HPjtune分析GC日志（一个实际案例的诊断过程）

hashei — Thu, 02 Jul 2009 08:48:14 +0000

上次介绍了IBM的两款分析gc log的工具（GCMV和PMAT），这次讲讲HP推出的HPjmeter。HPjmeter集成了以前的HPjtune功能，可以分析在HP机器上产生的垃圾回收日志文件。你可以到Hewlett-Packard Java website免费下载最新的4.0版本，当然会让你填一些信息。

接下来我将分析一个实际生产环境下的日志文件，这个生产系统在启用新的功能后应用访问速度变慢，每个操作都要耗时10s左右，通过对比前后不同的gc信息，希望能从JVM的层面来优化当前的性能。

HP小机（Pa-Risc和安腾平台）使用HP的JDK后，使用-Xloggc:filename或者-Xverbosegc:file=filename参数会生成形如

……

……

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

分析过程

用HPjmeter加载日志文件后，会自动打开HPjtune的窗口。首先会看到Heap Usage After GC标签页，这是四月份正常的情况（请先忽略systemgc，这点留待后面分析）

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

明显能看到Old full（with perm）代表的黄点增多了，从之前的日志文件头我们了解到这个系统所用的JDK为1.4.2 32位版本（64位版本会写明Java VM name = Java HotSpot(TM) 64-Bit Server VM），默认的回收策略是串行收集器，在Old区发生垃圾回收时是Stop the world的full gc，每次full gc耗时基本在10s～12s

切换到”Summary”标签页

4月花在gc上的时间占整个JVM运行时间的3.036%，Full GC占整个JVM运行时间的0.993%，应该说是情况良好。

到了6月份，情况却变化很大，时间分别为10.791%和8.417%，因为超过了5%的警戒线而显示为红色，而且79%的GC时间花在full gc上。

这还是一周的情况，包括了周末和晚间空闲时刻，让我们看看在上班高峰期间的运行情况。

乖乖，有61%的时间花在gc上，速度不慢才怪了。我们查看当前对应的Heap Usage After GC

除了开始的少数年轻代中发生的快速Scavenge，大部分都是慢速的Full GC，而且可以看到每次回收后使用的堆空间并没有减小，反而越来越大，有内存泄漏的征兆。不过堆空间并没有一路增长下去直到OutOfMemory，而是像下图般那样反复。

早上和下午两个业务繁忙期全是full gc，性能表现很差，而4月正常的情况应是如此

Eden区满了后，经过Scavenge动作一部分对象被转移到了Old区，所以堆中占用空间上升，直到Old区也无法分配了，那么发生full gc，内存又重新回到一个较低的位置，这是正常的情况。现在6月份出现一直Full GC也无法回收，但又没有发生OutOfMemory，可以判断为原来设置的参数无法满足新内容投产后的需求

例如没有使用并行回收，没有发挥8个CPU的效果，没有采用低响应时间的CMS回收模式。

同时新系统产生的对象数量也大大增加，从四月一天的500000个增加到900000个（左边四月，右边六月）。

导致每次回收后，从新生代转移到年老区的对象数量也变多，其实它们并非是长存对象，只是新生代暂时无法容纳下它们了。

而且full gc会导致Survivor区里的所有对象都被转移到old区，这造成了恶性循环。（黄色的Full GC后，Survivor里的对象为零）

优化操作

调整目标：尽可能的将短时间存活的对象在年轻代就能被丢弃掉，而不要转移到年老代中；采用并行回收方式增加效率；避免产生不必要的Full GC；或者采用响应时间短的垃圾回收方式。

调整方法：增大年轻代大小，减小SurvivorRatio加大Survivor区（也就是From or To）；设置并行回收参数;设置初始堆和最大堆为同样值、设置初始PermSize为一个合理值，避免运行过程中增长；设置回收策略为CMS。

参数设置一：-Xms1500m -Xmx1500m -Xmn800m -XX:SurvivorRatio=4 -XX:PermSize=160m -XX:+UseParallelGC（-XX:ParallelGCThreads=8我觉得可以不用显示的声明，可以再上述参数设置后分析新的gc log，看一下System Details页面中ParallelGCThreads的数目再做定夺，1.4.2的JDK不能再Old区做并行回收，也是一个遗憾）

参数设置二：-Xms1500m -Xmx1500m -Xmn800m -XX:PermSize=160m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSFullGCsBeforeCompaction=5（或者最后一个参数设置为-XX:+UseCMSCompactAtFullCollection）

上述参数的意义可以看《JAVA性能优化—Sun Hotspot JDK JVM参数设置》

后续进展

参数设置后还有一个观察过程，如果效果不佳，那从系统集成的角度，一是更换64位JDK，这样可以设置更大的堆空间（不过WebSphere更换JDK不像Weblogic那么简单，如果没有买过64位WebSphere的话只好作罢）；二是启用WebSphere的集群，但这需要ND版本的WAS。

从应用的角度，可以在早上8点做一次heapdump，9点半做一次heapdump，分析一下full gc内存回收不下来的原因，确定不是程序的错误造成的。或者启用-agentlib:hprof参数，用HPjmeter来trace应用的表现、用HPjmeter来直接监控应用的运行情况。不过这两个方法对性能影响较大，要在测试环境下进行。

其它的一些碎碎念

现在我们来说说日志中那么多的systemgc，刚开始看到我大吃一惊，但放大图像后发现这些自行调用的full gc都是下班后做的，应该是另一个应用触发的，对白天的性能影响应该不大。

不过这里还是要再申明一句：自行调用System.gc（）函数会损害到JVM的性能，因为这时候是Stop the World的回收，消耗的时间长，但效果并非最佳。你也许会认为你对程序很熟悉，可以在空闲的时间执行system.gc，不会影响到客户访问，但是正如之前所说，full gc后survivor里的所有内容都被转移到了old区长久保存，所以在某个将来，JVM就不得不因为这个原因再做一次不必要的full gc。

IBM JDK下避免主动回收的参数是“-Xdisableexplicitgc”，Sun JDK下的参数是“-XX:+DisableExplicitGC”，注意区别。

Copyright © 2008 This feed is for personal, non-commercial use only
聚沙成塔-小哈的记事薄 by hashei 如果喜欢，欢迎订阅feed.hashei.com
Digital Fingerprint: 10f920a9f2bae51c3c73c4f5fb50a949

WebSphere troubshooting-用工具分析GC Log

hashei — Tue, 09 Jun 2009 14:52:59 +0000

要进行gc performance tuning，不得不对gc log进行分析。之前说到了“人肉”的方法，总觉得不够形象，无法让不了解的开发人员抑或是技术负责人有个直观的了解，所以本文介绍几个分析GC log的工具。

首先需要下载IBM Support Assistant，下载之后就可以从Update-Tools add on中下载我们需要的工具了，ISA使用方法。ISA把所有的工具集成在一个界面内，省去了设置启动参数的麻烦，同时能保持最及时的更新。分析垃圾回收日志，我主要用“The IBM Monitoring and Diagnostic Tools for Java™ – Garbage Collection and Memory Visualizer”和“IBM Pattern Modeling and Analysis Tool for Java Garbage Collector (PMAT)”这两个工具。我会用实际例子来说明如何使用这个工具。

用Garbage Collection and Memory Visualizer载入native_stderr.log，首先你会看到

点击展开大图

这是一个500分钟的垃圾回收曲线图，可以观察到一天以内的大致情况。总的来说，蓝色的Used heap（after collection）运行在“平行通道”内，没有走“上升通道”（炒股的朋友应该知道上升通道的图形是咋样的）。所以在Report这个标签内，可以看到“The memory usage of the application does not indicate any obvious leaks.”。

Report中的Summary是需要关注的，它向我们显示了GC发生的次数，所用的policy（optthruput），平均停顿时间248ms，平均间隔时间3.37分钟，还有垃圾回收的速率（垃圾产生多并非不好，反而是吞吐率高的一种表现）。

让我们再切回Line plot视图，现在可以框选某一个时间段进行放大，同时在右边Axes中选择X轴的坐标系，默认的是相对时间，以分钟为单位，适用于你的应用程序总在启动N个小时后出现问题。如果是每天固定时间发生性能问题，那么应该选用绝对时间。

默认的曲线开启了Heap size和Used heap（after collection），你可以根据需要，在VGC Pause Date和VGC Date、VGC Heap Data中勾选你需要查看的曲线。比如你觉得程序响应时间很长，那么可以勾选上Intervals between garbage collection triggers和Pause time，看看上一条曲线是否和下面一条靠的“太近”。

通过在Tabbed data查看表格模式的回收信息（同样可以勾选上节提到的内容来增加列），我们看到GC reason都是af。通过查看Free heap before collection，我们发觉有些af发生的时候，堆中剩余空间其实还很多

我覆盖上Compact times曲线，发现十分吻合，原来这时候是堆中的碎片太多，所以导致即使剩余空间很大，但是没有连续空间分配给新的请求，这时候就发生了压缩（Compact）。加了Unuseable heap due to fragmentatiion的第二副图可以更明显的看到这一点。进一步的，可以根据第一列的collection id去查看引起压缩的requested_bytes，是否是需要比较大的空间（比如大于64K），然后结合一下所有requested_bytes中大对象的数量，确定是否需要调整LOA大小。

你会发现还有些曲线是灰色不能选择状态，那是因为根据我现在的gc policy，关于gencon模式下的nursery和tenured曲线在这个模式下是没有的。

总的来说，运用不同的曲线组合，合适的缩放比例，不同的日志显示方法对照，我们可以验证gc是否符合我之前说过的一些“最优原则”——回收的间隔是否大大大于持续时间，整个回收时间是否在整个运行时间的5%以下，压缩的次数是否仅占一小部分（太多的话要考虑设置-Xk -Xp和调整LOA）……Report标签中的Tuning recommendation是你需要参考的内容，但不要一上来就根据它的提示去优化。

下一个例子就是一个有问题的垃圾回收日志。

整个垃圾回收曲线，当中有一个Excessive GC引发的OutOfMemory

The concurrent collector will throw an OutOfMemoryError if too much time is being spent in garbage collection: if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, an OutOfMemoryError will be thrown. This feature is designed to prevent applications from running for an extended period of time while making little or no progress because the heap is too small.

放大出问题的地方的曲线

根据ID查看原始文件

=”low free space (less than 4%)” />

compact to aid heap contraction” />
excess free space following gc” />

考虑到垃圾回收频率也较高，每次请求的空间都不大，所以我讲垃圾回收模式改为了gencon，之后没有OutOfMemory发生。不过我那份回收日志没有留下来，否则应该在文件Compare file中导入修改后生成的日志，进行比较，确定修改的结果。

注意事项：对于IBM JDK，直接勾选“详细垃圾回收”即可，但是对于HP 或者Sun JDK，最好使用-Xverbosegclog:file_name（生成能解析的XML格式）来指定一下，否则默认文件中会包含其它信息，工具讲无法以图像显示，还要自己修改文件，比较麻烦的。

IBM Pattern Modeling and Analysis Tool for Java Garbage Collector (PMAT)这个工具大同小异，个人使用它只是觉得提供的优化建议可以和上述工具互补，比如它会计算一个适合的-Xk -Xp值出来。

对于HP-UX上生成的垃圾回收日志，我们还可以用HPjmeter下的HPjtune来分析。

JAVA性能优化-GC日志分析

hashei — Mon, 01 Jun 2009 15:16:14 +0000

前两篇说到IBM JDK和Sun的HotSpot JDK的调优策略，当中一直提到的重要一点是需要根据GC详细日志来调整参数的设置，那么当我们收集到日志后如何分析，如何根据日志的情况来调整参数？这就是本文所要阐述的。

使用IBM的JDK的Windows平台和AIX平台，我们只要在WebSphere管理控制台的java进程属性里勾选“详细垃圾回收”，那么就会在native_stdout.log中生成如下的信息。

这幅图很形象的给出了gc日志的主要关注点：垃圾回收的原因、垃圾回收的间隔、垃圾回收前后的剩余空间、垃圾回收持续的时间……

“nursery”表示这次分配失败（Allocation Failure）发生在新生代（nursery），是第44次（id=44）因为新生代的分配失败而进行垃圾回收了（开启GC日志以来），离上一次发生GC的间隔是12746ms，无法分配的空间大小是8216Byte，而进行垃圾回收前，新生代的可用空间为1776Byte，小于8216Byte，虽然年老区还剩余45%的空间，但是新的内存空间是无法直接在年老区分配的，由此引发了一次清理过程（scavenger）。

GC type表明了这次垃圾回收是一个清理过程，也是第44次scavenger过程，同时恰是第44个gc过程，说明没有发生过诸如的垃圾回收过程。flipped objectcount说明将要把4523143个存活下来的对象被复制到了幸存区（survivor space），而73768个对象则经过多次幸存区的复制，有幸熬出头，被转移到了长存区（tenured space）。我们看到清理的倾斜比率（scavenger tiltratio）为89%，而不是对半开，说明经过多次复制清理，JVM已经意识到每次只有很少的对象能存活下来，于是它自动增大了年轻代中Eden区的大小，以使得为新对象可以腾出更多的内存。

接下来的就比较简单，经过垃圾回收，新生代的空间剩余89%，因为分配失败发生在新生代，进行的是快速的Minor gc，所以长存区的可用空间依然是45%，这次回收的时间为384.469ms。在长存区发生的是Major gc，回收时间一般要长于Minor gc，所以健康的JVM 环境Minor gc：Minor gc=1：10（也不用太在意）。

在垃圾回收准备开始的那一段时间（time exclusiveaccessms），以及回收的过程中，另一个线程发现内存无法分配了，于是也要求一次gc过程，这时候就产生了gc队列（会有显示）。一般前一次垃圾回收就会释放出足够这两次分配需要的空间，于是第二次gc过程就终止了，当然要是无法足够分配的话，马上就会再进行一次垃圾回收。不过这种情况下，估计要进行Full GC了。

Full GC的gc type就是global，这是stop the world的最耗费时间的回收方式，所以需要通过尽量调整参数来避免。如果发现不是由AF引起的，而是在开头写着SYS标签，那么就要好好问问开发，有没有使用System.gc()的必要？可以的话使用-Xdisableexplicitgc来禁止（Sun等JDK下为-XX:+DisableExplicitGC）。

以上所说的都是IBM JDK下垃圾回收日志的情况。在Sun和HP的JDK下情况相似，不过需要使用-XX:PrintHeapAtGC:参数来打印GC前后的详细堆栈信息。另外我建议加上-Xloggc:filename或者-Xverbosegclog:file_name（方便用工具分析）输出到特定文件，因为不知为何有时候会输出到native_stderr.log，或者在native_stdout.log中和thread dump夹杂在一起，不方便分析。

{Heap before GC invocations=116:
Heap
def new generation   total 157376K, used 139904K [63400000, 6dec0000, 78950000)
eden space 139904K, 100% used [63400000, 6bca0000, 6bca0000)
from space 17472K,   0% used [6bca0000, 6bca0000, 6cdb0000)
to   space 17472K,   0% used [6cdb0000, 6cdb0000, 6dec0000)
tenured generation   total 349568K, used 79067K [38800000, 4dd60000, 632b0000)
the space 349568K, 22% used [38800000, 3d536ce0, 3d536e00, 4dd60000)
compacting perm gen total 132096K, used 132023K [28800000, 30900000, 38800000)
the space 132096K, 99% used [28800000, 308edf50, 308ee000, 30900000)
[GC 218971K->83116K(506944K), 0.0976948 secs]
Heap after GC invocations=117:
Heap
def new generation   total 157376K, used 4049K [63400000, 6dec0000, 78950000)
eden space 139904K,   0% used [63400000, 63400000, 6bca0000)
from space 17472K, 23% used [6cdb0000, 6d1a4628, 6dec0000)
to   space 17472K,   0% used [6bca0000, 6bca0000, 6cdb0000)
tenured generation   total 349568K, used 79067K [38800000, 4dd60000, 632b0000)
the space 349568K, 22% used [38800000, 3d536ce0, 3d536e00, 4dd60000)
compacting perm gen total 132096K, used 132023K [28800000, 30900000, 38800000)
the space 132096K, 99% used [28800000, 308edf50, 308ee000, 30900000)
}

这是一个在使用HPJDK输出的实例，基本和IBM JDK没啥区别，可以加上-XX:+PrintGCTimeStamps显示每次回收的间隔。

这些“人肉”分析可以让我们清楚JVM运行的情况，但是还是不够直观，所以下次会介绍分析JVM日志的工具，尽情期待。现已完成，欢迎访问

聚沙成塔-小哈的记事薄 » gc performance tuning

用HPjtune分析GC日志（一个实际案例的诊断过程）

分析过程

优化操作

后续进展

其它的一些碎碎念

Related posts:

WebSphere troubshooting-用工具分析GC Log

Related posts:

JAVA性能优化-GC日志分析

Related posts: