需要垃圾收集开销帮助答案

【问题标题】：Garbage Collection Overhead Help Needed需要垃圾收集开销帮助
【发布时间】：2011-10-12 23:10:45
【问题描述】：

在尝试诊断 GC 相关问题时，我正在寻找一些指导。

我们正在使用 WebSphere Portal 在 Solaris 上进行测试，我当前环境的垃圾收集开销为 7%（这是使用详细 GC 计算并通过 PMAT 运行日志）我应该将此值与另一个正在运行的环境进行比较平均为 4.5%。 env 在完全相同的 WebSphere Portal 版本上，相同的 JVM 大小、参数、自定义变量等。在 1 小时的性能测试期间，我的 JVM 有 20 次以上的分配失败，2 次以上的完整 GC，GC 期间的平均暂停时间比其环境高 2 秒。

对于所有相同的配置值和完全相同的 1 小时性能测试，您能否就导致此问题的原因给我任何建议？或者还有什么要审查的？

谢谢

【问题讨论】：

这两台机器是否运行在100%公平的负载均衡环境中？相同的虚拟机和相同的硬件？
是的，它们运行在 100% 公平的负载平衡环境中。相同的硬件，非虚拟化。我实际上发现了一个很大的不同，当他们运行测试时，他们有 JVM 设置，其中包括： -XX:ParallelGCThreads=32 然后他们稍后将其更改为 -XX:ParallelGCThreads=8。我们将 env 设置为 8 以匹配他们的环境，而不知道在我们进行比较的测试期间它被设置为 32。仅此一项就可以解释差异吗？
坦率地说，7% 的开销非常低。（当然，Sun JVM 严重低估了 GC 开销，但这是另一回事。）
谢谢 Daniel，我同意你的观点，但 mgmt 询问为什么它比其他环境数字高 2%。我还确认服务器有 32 个 CPU，因此通过设置我们的 env XX:ParallelGCThreads=8 可以解释与设置为 XX:ParallelGCThreads=32 的 env 的区别。有人认为这会导致额外 2% 的开销吗？
可能，因为您将使用更少的内核来执行 GC。

标签： java garbage-collection websphere-portal performance-testing

【解决方案1】：

如果您运行不同的操作系统，它们可能会在相同的设置下执行不同的操作。最佳 GC 设置和线程池大小可能不同。我记得至少在 Solaris 与 RedHat 的情况下，最佳并发设置明显不同。

【讨论】：

【解决方案2】：

我要检查的第一件事是进程是否被推入交换/“虚拟”内存。这将对您的 GC 开销产生重大影响。

对于相同的 Java 配置和负载等，最明显的区别是每台机器上的物理 RAM 量。假设它们是相同的，请查看每台机器上运行的其他进程/服务 - 除非它们都是相同操作系统的全新安装，否则我预计会有一些（潜在的显着）差异。

发布来自top 和iostat（或您的首选工具）的输出，我们会看看是否有任何明显的地方。

【讨论】：