9

我正在升级生产硬件，与旧套件相比，我们在新套件上看到了更多的年轻一代 GC。

相同的程序在两台机器上运行（相同的二进制文件）。一个明显的区别（我希望这不会对 JVM 产生影响）是我们升级了 RHEL5 -> RHEL6。

我们的 JVM（Java 64 位 Hotspot 1.6，java -version两者相同）使用相同的命令行 GC 选项运行：

-XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseParallelGC -XX:+UseCompressedOops

还：

-Xmx1024M -Xms1024M -XX:NewSize=512M -XX:SurvivorRatio=2

机器之间的区别在于，新机器的 RAM 大约是原来的两倍（32gb尽管最大堆没有改变）和更多的内核（24 对 16）。

应用程序本身连接到多个外部进程并执行大量网络操作 - 因此这可能表明存在一些回归、错误配置或不兼容（这就是我们测试的原因......）。我想知道的是：

增加年轻代 GC 的水平是否可能是在更多内核上运行的自然和预期结果，还是我应该关注这种发展？

我们在 JConsole 中确认了 GC 的数量，但这与执行以下操作大致相同：

grep "PSYoungGen" ./log | wc -l

（注-XX:+PrintGC -XX:+PrintGCDetails）

两个盒子上的完整 GC 看起来差不多。

请注意，这是整个应用程序启动过程中的 GC 数量 - 因此它没有执行“更多工作”。这是相同的工作，需要更多的 GC 运行。

例如，我想知道是否-XX:+UseParallelGC会导致日志中出现更多条目，因为正在使用更多线程（将年轻一代的集合切割成更小的部分，这意味着更多、更小的集合——不用担心）。

4

2 回答 2

1

令人费解的问题...

简短的回答

不，GC 频率只是您的创建率的函数。除非您的应用程序利用了这个新硬件，否则 GC 频率应该是相同的。

长答案

我认为这与操作系统升级无关，我认为总 RAM 的增加也与此无关。

它不能来自指针大小的增加，因为最大堆大小为 1GB。因此 JVM 已经使用 32 位指针，即使您使用的是 64 位 JVM。

您的应用程序在启动期间是否使用了所有内核？

这可以解释 YoungGC 率的增加：如果您的应用程序使用 8 个以上的线程，这意味着它将在相同的时间内执行更多的工作。您应该观察到分配率的增加（请参阅您的 GC 日志）。

您还应该注意到年轻 GC 持续时间的下降，因为 PSScavenge 使用了更多线程。这个对吗 ？

根据这个页面，ParallelGCThreads = (ncpus <= 8) ? ncpus : 3 + ((ncpus * 5) / 8)。你在一个 YGC 循环中使用了 13 个线程，现在使用了 18 个。

于 2013-05-16T15:18:12.410 回答
-3

这取决于您的操作系统架构（x64 或 x86）和 x86，jvm 上升到 4Gb，x64 上升到 2Gb（RAM ammount）。

于 2013-05-16T14:42:30.493 回答