增加可用内核和RAM的数量会导致JVM执行更多GC吗?

jel*_*ord 9 java garbage-collection jvm

我正在升级生产硬件,而且我们在新套件上看到了比旧款更多的年轻人GCing.

两台机器上运行相同的程序(相同的二进制文件).一个明显的区别(我希望这对JVM没有影响)是我们升级了RHEL5 - > RHEL6.

我们的JVM(Java 64位Hotspot 1.6,java -version两者都相同)使用相同的命令行GC选项运行:

-XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseParallelGC -XX:+UseCompressedOops
Run Code Online (Sandbox Code Playgroud)

也:

-Xmx1024M -Xms1024M -XX:NewSize=512M -XX:SurvivorRatio=2
Run Code Online (Sandbox Code Playgroud)

这些机器之间的区别在于,新机箱的内存大约是RAM的两倍(32gb尽管最大堆不变),还有一些内核(24比16).

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

增加的年轻GC水平可能是运行更多核心的自然和预期后果,还是我应该关注这一发展?

我们在JConsole中确认了GC的数量,但这与做的大致相同:

grep "PSYoungGen" ./log | wc -l 
Run Code Online (Sandbox Code Playgroud)

(注-XX:+PrintGC -XX:+PrintGCDetails)

完整的GC在两个盒子上看起来大致相同.

请注意,这是整个应用程序启动过程中GC的数量 - 因此它不会执行"更多工作".这是同样的工作,有更多的GC运行.

例如,我想知道是否-XX:+UseParallelGC会在日志中导致更多的条目,因为正在使用更多的线程(将年轻的集合切成小块,意味着更多,更小的集合 - 不用担心).

Pie*_*rte 1

令人费解的问题...

简短回答

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

长答案

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

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

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

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

您还应该注意到 Young GC 持续时间有所下降,因为 PSScavenge 使用更多线程。它是否正确 ?

根据此页面ParallelGCThreads = (ncpus <= 8) ? ncpus : 3 + ((ncpus * 5) / 8). 您之前在一个 YGC 周期中使用 13 个线程,现在使用 18 个线程。