java - 垃圾收集调整生产应用程序

Question

我的任务是调整一个生产应用程序，该应用程序由一个 Spring MVC REST 接口(interface)组成，服务于来自内存缓存后端中的 Gemfire 的大型 (~0mb - 100mb) json 文档。该应用程序在 JDK 1.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 秒发生一次，持续时间约为 0.04 秒。老年代在 48 小时后根本没有增长，并且该空间中有 0 个集合。

我的问题是我应该担心没有收集老年代的垃圾吗？总体而言，这看起来像是一个健康的调整吗？

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

Answer 1

My question is should I be concerned about not having the old generation garbage collected?

日志看起来不错。鉴于趋势，老一代的入住率增长非常缓慢。因此，它需要几天时间才能满到足以启动并发标记周期。

Overall does this look like a healthy tuning?

看起来你给它的内存比它需要的多得多。

老一代占用率在2G/12G左右。这意味着您可能会将其缩小到 4G，但在并发周期开始之前仍需要花费数小时

大多数年轻对象在年轻一代中只能活到 1 岁(满分 15 岁)。这意味着年轻一代也可以缩小，而不会过多地增加对象提升

-XX:CMSInitiatingOccupancyFraction=70

这应该与 XX:+UseCMSInitiatingOccupancyOnly 结合使用