如何确定 jvm 应用程序执行的 GC 比正常工作多？答案

【问题标题】：How to determine that a jvm app does more GC than normal work?如何确定 jvm 应用程序执行的 GC 比正常工作多？
【发布时间】：2016-12-02 19:51:54
【问题描述】：

我们最近遇到了一个问题，即我们的 EC2 实例有 90-100% 的 cpu 负载，这是因为我们包含一个库中的一个错误，该库为许多对象创建而不是重用它们（这很容易解决），所以我们花了太多时间在 GC 中。

不幸的是，AWS 运行状况检查和实例状态指标并没有导致过载的实例停止，然后新的实例重新启动，所以一段时间后我们达到了最大自动缩放数量并且......死了。此外，我们自己在应用程序中用于 ELB 的运行状况检查非常简单，以至于它们回答的频率足够高，显然不会导致实例被终止......并重新启动，这将在相当长的一段时间内缓解该问题。

我现在的想法是，如果我们在 GC 上花费了太多时间，则使用我们已经包含在 ELB 健康检查中的自定义健康检查来报告失败。

我将如何在应用程序内做这样的事情？

【问题讨论】：

所有不错的建议，但我不想通过工具连接，而是从应用程序内部报告它，例如通过 Http 调用。所以我也想从内部计算它......
GCTimeRatio 实际上应该防止这种情况发生，并在花费太多时间在 GC 上时抛出超出 OOME 的开销限制。
我们的应用并非如此。它仍然有响应，但还不够好。对于 3 个实例，我们每分钟大约有 5000 到 20000 个请求
默认情况下，取决于配置，大约 1% 到 15% 的 GC 开销。除非您覆盖了一些相关的 JVM 参数，否则我希望会发生 OOME。

标签： amazon-web-services garbage-collection jvm amazon-elb autoscaling

【解决方案1】：

有许多JVM参数允许GC监控

-Xloggc:<file> // logs gc activity to a file
-XX:+PrintGCDetails // tells you how different generations are impacted

您可以自己解析这些日志，也可以使用 GCViewer 等特定工具来分析 gc 活动。

【讨论】：

从应用程序内部？
我明白了...没有尝试过，但 GarbageCollectionNotificationInfo 似乎可以满足您的需求。

【解决方案2】：

使用GarbageCollectorMXBean:

    long gcTime = 0;
    for (GarbageCollectorMXBean gcBean : ManagementFactory.getGarbageCollectorMXBeans()) {
        gcTime += gcBean.getCollectionTime();
    }

    long jvmUptime = ManagementFactory.getRuntimeMXBean().getUptime();

    System.out.println("GC ratio: " + (100 * gcTime / jvmUptime) + "%");

【讨论】：

【解决方案3】：

您可以使用VisualVM 来监控 JVM 内部发生的事情，您可以通过 JMX 监控远程实例。您没有描述您正在使用哪个应用程序容器（Apache Tomcat、GlassFish 等），您可以在 Tomcat 的情况下设置 JMX 连接器like this。

不要忘记调整 AWS 中的安全组以拥有访问 JMX 端口的适当权限。

【讨论】：

我们不使用任何容器。我们使用play框架。因此我们想从应用程序内部使用/计算它
我知道这些工具，但我想从应用程序内部计算它并让 ELB 决定通过检查状态代码来终止实例。例如。如果我们在 GC 上花费超过 75%，我们将交付非 200 个代码。

【解决方案4】：

JVM 标志PrintGCApplicationConcurrentTime 和PrintGCApplicationStoppedTime 将记录应用程序处于活动状态或挂起状态的时间。它们有点用词不当，因为它们实际上衡量的是进出安全点的时间，而不仅仅是 GC。

【讨论】：

我想从应用程序内部计算它