优化生产应用程序的垃圾收集

Question

我的任务是调优一个生产应用程序，该应用程序由一个Spring接口组成，用于从内存缓存后端的Gemfire提供大型(~0mb -100 0mb) json文档。应用程序运行在JDK1.6上Tomcat 7内的CentOS服务器上。我们意识到，需要对应用程序进行调优，因为我们经常看到停止世界旧代垃圾收集，如果没有人参与，这最终会导致java.lang.OutOfMemoryError: GC overhead limit exceeded错误。

通过一些尝试、错误和监视，我设法用以下参数调优了应用程序：

-Xms20g 
-Xmx20g 

-XX:PermSize=256m 
-XX:MaxPermSize=256m

-XX:NewSize=8g 
-XX:MaxNewSize=8g

-XX:SurvivorRatio=8
-XX:+DisableExplicitGC
-XX:+UseConcMarkSweepGC 
-XX:+UseParNewGC
-XX:CMSInitiatingOccupancyFraction=70

我现在看到的垃圾收集行为(在重测试负载下的48小时)是，伊甸园空间收集大约每10秒进行一次，并持续大约.04秒。老一代在48小时后根本没有增长，在这个空间里已经有了0种收藏。

我的问题是，我是否应该担心不收集老一代的垃圾？总的来说，这看起来像一个健康的调优吗？

编辑：对于任何关心我的GC日志的人，都可以在这里找到http://filebin.ca/2U8awo1KTS1D/udf-gc.log.0

Answer 1

我的问题是，我是否应该担心不收集老一代的垃圾？

原木看上去不错。考虑到这种趋势，旧一代的占用率增长非常缓慢。因此，它将需要几天，直到它变得足够充分，一个并行的标记周期被启动。

总的来说，这看起来像一个健康的调优吗？

看起来你给它的记忆比它需要的要多。

老世代占用率在2G / 12G左右。这意味着您可能会将其缩小到4G，并且在并行循环开始之前仍要花费许多小时。

在年轻一代中，大多数年轻物体只活到1岁(在15岁中)。这意味着年轻一代可能也会萎缩，而不会增加太多的宣传对象。

-XX:CMSInitiatingOccupancyFraction=70

应该与XX:+UseCMSInitiatingOccupancyOnly相结合

Answer 2

对一般性能优化来说，调优垃圾回收没有什么不同，因为如果没有需求，您可以(至少对于非平凡的应用程序)有效地不断改进。在某种程度上，改进对实际用例不再重要。这就是你应该制定目标的原因。

有关GC的目标应该来自一般性能要求。这些通常是用来描述三维的。

• 延迟。或者更准确地说，应用程序发布的每个服务都可以接受延迟分布。例如，99%的登录()操作必须在500 99以下完成，最坏的情况是不能超过2500 99。
• 吞吐量。每个时间单位必须完成多少次操作。对于大型monoliths更难度量，但是如果运行微服务，您可以将其表示为“每秒处理1,000个登录操作”。
• 容量。增加更多的资源和扩大规模将改善这种情况，但在实际问题上，如每月AWS法案将在这方面设定限制。

有了这些需求，您就可以开始构建/派生它们，并在必要时进一步优化。我所属的公司最近出版了一本关于GC调优的相当详尽的手册，以便您可以从手册的GC调谐段中查看更多内容。