如何监控Java垃圾回收机制6

分析GC优化结果

在设置了GC参数以及-verbosegc参数之后，通过tail命令确保日志被正确的生成。如果参数设置的不正确或者日志没有生成，你将白白浪费你的时间。如果日志正确的话，持续收集1到2天。随后最好将日志下载到本地PC并用HPJMeter来分析

• Full GC 执行时间
• Minor GC执行时间
• Full GC 执行间隔
• Minor GC 执行间隔
• Entire Full GC 执行时间
• Entire Minor GC 执行时间
• Entire GC 执行时间
• Full GC e执行时间
• Minor GC 执行时间

找到最佳的GC参数是件非常幸运的事情，然而在大多数场合，我们并不会得到幸运之神的眷顾，在进行GC优化时要尽量小心谨慎，想一步完成优化往往会导致OutOfMemoryError 。

优化示例

好了，我们一直在纸上谈兵，现在我们看一些实际的GC优化的例子。

示例1

下面这个例子针对 Service S的优化,对于最近被部署的 Service S，Full GC花费了太长的时间。

请看 jstat –gcutil的执行结果。

1 2	S0 S1 E O P YGC YGCT FGC FGCT GCT 12.16 0.00 5.18 63.78 20.32 54 2.047 5 6.946 8.993

最左边的Perm 空间对于最初的GC优化不是很重要，这一次YGC参数的值更加有用。

Minor GC和Full GC的平均值如下表所示

表3：Service S的Minor GC 和Full GC的平均执行时间

GC 类型	GC 执行次数	GC 执行时间	平均
Minor GC	54	2.047	37 ms
Full GC	5	6.946	1,389 s

最重要的是下面两个数据

• 新生代实际使用空间: 212,992 KB
• 老年代实际使用空间: 1,884,160 KB

因此，总的内存空间为2GB,不算Perm空间的话，新生代与老年代之比为1:9。通过jstat和-verbosegc 日志进行数据收集，并把三台服务器按照如下方式设置。

• NewRatio=2
• NewRatio=3
• NewRatio=4

一天之后，检查系统的GC日志后发现，在设置了NewRatio参数后很幸运的没有发生Full GC，

为什么？

• NewRatio=2: 45 ms
• NewRatio=3: 34 ms
• NewRatio=4: 30 ms

我们看到NewRatio=4 是最佳的参数，虽然它的新生代空间最小，但GC时间确最短。设定这个参数之后，系统没有执行过Full GC。

为了说明这个问题，下面是服务之星一段时间后执行jstat –gcutil的结果

1 2	S0 S1 E O P YGC YGCT FGC FGCT GCT 8.61 0.00 30.67 24.62 22.38 2424 30.219 0 0.000 30.219

你可能会认为因为服务器接受的请求少才导致的GC执行频率下降。实际上，虽然Full GC没有执行，但是Minor GC被执行了 2,424次。

示例2

这是一个针对ServiceA的例子，我们通过公司内部的应用性能管理系统（APM）发现JVM暂停了相当长的时间（超过8秒），因此我们进行了GC优化。我们找到了Full GC执行时间过长的原因，并着手解决。

进行GC优化的第一步，就是我们添加了-verbosegc参数，并得到如下结果。

 

图1：进行GC优化之前的STW时间

如上图所示，由HPJMeter自动生成的图片之一。X坐标表示JVM执行的时间。Y坐标表示每次GC的时间。CMS绿点，表示Full GC结果。Parallel Scavenge蓝点，表示Minor GC结果。

之前我曾经说过CMS GC是最快的，但是上面的的结果显示出于某种原因，它最多花费了15秒。是什么导致这个结果？是否想起我之前提过的，CMS在进行内存清理时，会变慢。与此同时，服务的内存被设定为 –Xms1g和–Xmx4g ，且实际分配了4GB内存。

因此，我将GC类型从CMS改为Parallel GC。并且将内存改为2GB，设定NewRatio 为3。几小时之后我使用 jstat –gcutil得到如下结果

1 2	S0 S1 E O P YGC YGCT FGC FGCT GCT 0.00 30.48 3.31 26.54 37.01 226 11.131 4 11.758 22.890

相对于4GB时的15秒，Full GC变成了平均每次3秒。但是3秒一样比较慢，因此我设计了如下6种场景。

• Case 1: -XX:+UseParallelGC -Xms1536m -Xmx1536m -XX:NewRatio=2
• Case 2: -XX:+UseParallelGC -Xms1536m -Xmx1536m -XX:NewRatio=3
• Case 3: -XX:+UseParallelGC -Xms1g -Xmx1g -XX:NewRatio=3
• Case 4: -XX:+UseParallelOldGC -Xms1536m -Xmx1536m -XX:NewRatio=2
• Case 5: -XX:+UseParallelOldGC -Xms1536m -Xmx1536m -XX:NewRatio=3
• Case 6: -XX:+UseParallelOldGC -Xms1g -Xmx1g -XX:NewRatio=3

那一个最快呢？结果显示，内存越小，结果越好。下图展示了Case6的结果。这是GC的性能最好。最长的响应时间只有1.7秒。平均时间在1秒之内。

 

 

图2：Case6的时间图表

基于以上结果。我们按照Case6调整了GC参数。但是，这导致了每天晚上都会发生OutOfMemoryError。在这里很难解释具体的原因。简单来说，批处理程序导致了内存泄漏。相关的问题已经被解决。

如果对GC日志只分析很短的时间就贸然对所有服务器进行优化是非常危险的。请时刻牢记，你必须同时分析GC日志和应用程序。

我们回顾了两个关于GC优化的例子，正如我之前提到的，例子中提到的GC参数，可以设置在相同的服务器之上，但前提是他们具有相同的CPU，操作系统，JDK版本以及运行着相同的服务。但是不要直接把我用过的参数用到你的服务至上，它们未必能很好的工作。

结论

我凭借经验进行GC优化，而没有执行堆转储并分析内存的详细内容。精确地分析内存可以得到更好的优化效果。但是，这种分析一般适用于内存使用量相对固定的场合。不过，如果服务严重过载并占用的大量的内存，强力建议根据之前的经验进行GC优化。

我已经在一些服务上设置了G1 GC参数，并进行过性能测试。但还没有应用与正式环境，G1 GC参数的速度要快于其他任何GC类型。但是，你必须要升级到JDK7。另外，他的稳定性也暂时没有保障，没人知道是否会出现致命的错误。因此还不到将其正式应用的时候

在未来的某一天，等到JDK7真正稳定了（这不是说他现在不稳定），并且WAS针对JDK7进行优化后，G1 GC最终能够按照预期的那样工作了，我们可能就不需要在进行GC优化了。

想了解GC优化的更多内容，请登录Slideshare.com 查看关联资源。强烈推荐Everything I Ever Learned About JVM Performance Tuning @Twitter。作者Attila Szegedi，一位Twitter工程师。请花些时间阅读。

By Sangmin Lee, NHN Performance Engineering Lab.

作者Sangmin Lee，就职于NHN性能工程研究院

英文原文：cubrid，编译：ImportNew-王晓杰

译文地址： http://www.importnew.com/3146.html

【如需转载，请在正文中标注并保留原文链接、译文链接和译者等信息，谢谢合作！】