java - JVM 性能在随机时间后下降

Question

简而言之，我遇到了一个性能问题，该问题“随机”出现在 1 个 JVM 中，而该问题之前可能已经运行了好几天，但我似乎无法找到根本原因。我倾向于吃掉线程池的东西，但一直无法追踪到它。

我已经尝试了所有我能想到的方法来追踪这个问题，任何建议都会很棒!

(我可以使用 Jprofiler、yourkit 和 jvisualvm，并且我尝试过使用它们全部运行并在 JVM 内运行比较)

这是设置。我们在频繁使用的测试环境中运行 40 个 JVM(每台硬件机器 10 个)。他们使用名为 UltraESB(2.3.0) 的开源产品，该产品利用线程池进行异步请求/回复处理，但在我们的例子中，基于无状态 header 的 JMS 消息路由。我们的开发环境中有一个不太重但仍然常用的设置，我们从未见过这个问题。

因此，我们会看到相当频繁的次要 GC(每隔几分钟一次)，而很少看到主要 GC(每天一次左右)。我们在 centos 6.7 上使用热点 Java 1.7_71(Haswell CPU 错误已修补)

偶尔(对我来说似乎完全是随机的)其中一个 JVM 会开始表现不佳(我们有关于应用程序性能的监视器和指标)。正常情况下，我们会在 <1 毫秒内处理一条消息。一旦遇到错误场景，我们就会开始看到数百(100-200)毫秒的处理时间。当我们在几周内运行这些程序时，我们会看到几个性能不佳的 JVM。回收可以清理干净东西，并且它们还能正常运行几天。当 JVM 出错时，我们开始发现它们的处理时间与遇到性能问题的其他实例(包括其他硬件上的实例)几乎完全相同。这并不太奇怪，因为它们具有完全相同的代码库和 JMS 负载平衡循环，因此它们处理的消息数量几乎相同。

我通过打开 CPU 性能分析来触发此性能影响。看图:Blue was good process until I turned on CPU tracing and it started to perform poorly

有趣的是，即使禁用分析后，性能仍然不佳。

我尝试过测量的东西

我所尝试过的一切都没有给我带来任何 Elixir 。

GC 监控 - GC 持续时间和 CPU 利用率在引用 JVM 和性能不佳的 JVM 之间似乎是一致的。

GC 启动选项:

GC_OPTS="-XX:+PrintGCDetails \
-XX:+UseG1GC \
-XX:MaxGCPauseMillis=100 \
-XX:+ParallelRefProcEnabled \
-XX:+UnlockExperimentalVMOptions \
-XX:-ResizePLAB \
-XX:G1NewSizePercent=50 \
-XX:G1MaxNewSizePercent=50 \
-XX:+PrintAdaptiveSizePolicy \
-Xloggc:/logs/applogs/${instancename}/gc.${DATE}.log"

CPU 采样JVM 内部发生了很多事情，对我来说没有什么区别。打开此功能会导致问题，但并不总是取决于采样设置。

线程池使用统计信息导出为 MBean，线程池(spring 3.2.4 ThreadPoolTask​​Executor)和使用中的线程看起来与其他性能良好的实例相同。

Answer 1

您可以尝试http://mevss.jku.at/AntTracks 。它是一个研究 JVM，记录你的内存行为。然后，它能够显示随时间变化的堆属性，并根据跟踪在任何时间点离线可视化堆。该虚拟机的构建对行为影响尽可能小，因此不会像配置不当的采样那样扭曲应用程序行为。当然，只有当您期望内存/GC 在您的问题中发挥作用时，这才会有帮助。