Java 需要垃圾收集开销帮助

我正在寻找一些关于诊断GC相关问题的指导

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

对于相同的配置值和相同的精确1小时性能测试，您能给我一些建议吗？还有什么要复习的吗

---

谢谢

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

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

---

发布

top

和

iostat

（或您喜欢的工具）的输出，我们将查看是否有任何明显的信息。

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

这两台机器是否运行在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。