【发布时间】：2015-12-23 20:41:12
【问题描述】：
简而言之，我遇到了一个性能问题，一次“随机”出现在 1 个 JVM 中，之前可能已经运行了好几天，但我似乎找不到根本原因。我倾向于某种东西占用线程池，但一直无法找到它。
我已经浏览了所有我能想到的来追踪这个问题，任何建议都会很棒！
（我有 Jprofiler、yourkit 和 jvisualvm 供我使用，我已经尝试使用它们全部运行并在 JVM 中运行比较）
所以这是设置。 我们在一个频繁使用的测试环境中运行 40 个 JVM（每台硬件机器 10 个）。他们使用名为 UltraESB(2.3.0) 的开源产品，该产品利用线程池进行异步请求/回复处理，但在我们的案例中，是基于无状态标头的 JMS 消息路由。 我们的开发环境中有一个不太重要但仍然常用的设置，我们从未见过这个问题。
所以我们看到非常频繁的次要 GC（每隔几分钟一次）而很少看到主要 GC（一天左右一次）。我们在 centos 6.7 上使用热点 Java 1.7_71（Haswell CPU 错误已修补）
偶尔（对我来说似乎完全随机）其中一个 JVM 将开始表现不佳（我们有监控器 + 应用程序性能指标）。在正常情况下，我们会在
我通过打开 CPU 性能分析触发了这种性能影响。 看图：Blue was good process until I turned on CPU tracing and it started to perform poorly
有趣的是，即使禁用了性能分析，性能仍然很差。
我试过测量的东西
我所尝试的一切都没有让我找到任何灵丹妙药。
GC 监控 - 参考 JVM 和性能不佳的 JVM 之间的 GC 持续时间和 CPU 利用率似乎一致。
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 ThreadPoolTaskExecutor）和使用的线程似乎与其他性能良好的实例相同。
【问题讨论】：
-
您看到“病态”JVM 与正常 JVM 的 CPU 利用率有什么变化吗？ RSS有什么不同吗？如果你对他们运行
pstack或pmap有什么明显不同吗？ -
G1gc 在您保留大部分默认值时运行良好。不要碰年轻一代的尺寸。看看这个帖子：stackoverflow.com/questions/8111310/…
-
对 pstack 或 pmap 不太熟悉，原始 pmap 没有什么特别突出的。 RSS：性能不佳的 JVM 有 2.3g 的常驻内存，而健康的 JVM 有 1.4/1.5g 似乎存在一些差异。此外，我更频繁地看到繁忙的 JVM 上的 CPU 峰值（但它似乎与我的分析中的 GC 不一致）。它会暂时跳升，但不会超过顶部采样周期。
标签： java multithreading performance garbage-collection jvm