垃圾收集调整生产应用程序答案

【问题标题】：Garbage collection tuning a production application垃圾收集调整生产应用程序
【发布时间】：2016-01-20 15:54:21
【问题描述】：

我的任务是调整由 Spring MVC REST 接口组成的生产应用程序，该接口为内存缓存后端中的 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

【问题讨论】：

您的所有对象都在移至旧代之前被收集，因此您不会遇到问题。唯一的问题是您的 Java 应用程序保留的大量内存永远不会被使用。
查看 JDK 中提供的 jstat 工具。找出Tenuring阈值以及Old Generation上升的速度（如果有的话）会很好。如果之前你有小的年轻代，那么很可能Tenuring Threshold 很小，并且许多临时对象被移动到老年代导致通常完整的gcs。
我不会担心“没有收集旧代垃圾”。老年代保持稳定就好了，这是你的App所需要的。
第一个：JVM 很古老，升级。第二：开启GC日志并提供日志。
@the8427 我确实启用了 GC 日志记录。如果您愿意查看日志，请告诉我，我会给您一个链接。

标签： java garbage-collection

【解决方案1】：

我的问题是我应该担心没有收集旧代垃圾吗？

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

总的来说，这看起来是一个健康的调整吗？

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

老一代的占用大约是 2G / 12G。这意味着您可能会将其缩小到 4G，但仍需要数小时才能开始并发周期

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

-XX:CMSInitiatingOccupancyFraction=70

那应该和XX:+UseCMSInitiatingOccupancyOnly结合起来

【讨论】：

【解决方案2】：

从某种意义上说，调整垃圾收集与通用性能调整没有什么不同 - 在没有要求的情况下，您可以（至少对于非平凡的应用程序）有效地永远保持改进。在某些时候，改进对于实际用例不再重要。这就是为什么您应该制定目标。

有关 GC 的目标应源自通用性能要求。这些通常依次描述三个维度

延迟。或者更准确地说，应用程序发布的每个服务可接受的延迟分布。例如 - 99% 的 login() 操作必须在 500 毫秒内完成，最坏的情况不能超过 2,500 毫秒。
吞吐量。每个时间单位必须完成多少操作。大型单体应用更难衡量，但如果运行微服务，您可以将其表示为“每秒处理 1000 次登录操作”。
容量。添加更多资源和横向扩展将改善这种情况，但对于实际问题，诸如每月 AWS 账单之类的事情将在这方面设置限制。

满足这些要求后，您可以开始构建/派生它们，并在必要时进一步优化。我所属的公司最近出版了一本关于 GC 调优的相当详尽的手册，因此您可以从手册的GC tuning sections 中查看更多信息。

【讨论】：