Windows Server 2008上的64位Java 8或多或少使用整个服务器CPU

在从32位（oracle 8u33）过渡到64位（oracle 8u66也是102）的过程中，我们遇到过这样的情况：单个java进程使用机器的所有16个内核，或者在启动后5-15分钟的更长时间内使用>50%。我们的日志表明，由于较长时间内性能不佳，大量I/O（即通过hibernate写入MySQL）的周期被延长。一旦输出写入频率降低，cpu将返回到已知的低值

我们从未见过如此极端的cpu使用率。我们的应用程序相当于I/O，而不是CPU资源密集型。它通常需要远少于一个内核。我们在windows服务器上运行它已经有6年了

我的假设是，当堆变紧时（64位版本使用相同的xmx设置），jvm会不惜一切cpu成本来避免“堆外”情况：

• 当堆使用率达到比配置的最大大小低约70MB的“上限”时，VisualVM显示高cpu（主要是与GC无关的cpu！）
• 事实上，在增加堆大小->高cpu症状消失之后

虽然我知道解决方法，但我在这里输入的目标是两件事：

• 有人能证实这个假设吗
• 进一步了解jvm正在做什么以及为什么—它是特定于v8/64位/windows的吗
• 如何调整jvm行为以不影响其他进程（我们在一台服务器上有>50个实例），而是放弃、耗尽内存和死亡（我们有可用性监控，可以跟进）

提前谢谢

（与64位版本使用的xmx设置相同）

jvm在64位上使用的内部结构将消耗比32位更多的内存（结构对齐和指针大小，如果没有其他东西的话）-保持相同的最大堆大小（-Xmx）会带来麻烦

经过一些挖掘：

• “64位上需要30-50%的堆”以及“更长的垃圾收集暂停时间”

• 很抱歉，这是针对java5 Oracle的常见问题解答—需要将-Xmx从过多的值中调低，并使用

  -Xincgc

  来避免那些长的CG时间

当64位jvm内存不足时，我们看到的是“正常的”。 默认情况下，它将非常积极地使用如此多的并行线程运行GC，整个服务器都会受到影响

因为我们有很多JVM在运行，所以我们不希望在其中一个JVM内存不足时对所有其他JVM产生影响。解决方案是使用单线程gc:

-XX:+UseSerialGC

（并限制元空间

-XX:MaxMetaspaceSize=512m

）。从那时起——大约一年前——JVM表现良好。

---

jvm的默认设置似乎被调整为单独在服务器上

听起来像是实际上您的内存受限，并且您的堆限制对于您的工作集来说太低。如果您不增加堆大小，特别是如果您已经接近限制，则可能会发生这种情况。如果你想减少开销，我建议你将工作尺寸最大增加3倍。也许由于您的机器相当旧，您的内存使用受到限制。注意：现在一台典型的服务器的内存是32GB-128GB，而留出几GB的主机空间是不常见的。在我看来，这是几个不相关的问题。一个是关于如何解决一个JVM的资源耗尽问题，另一个是如何协调一台机器上多个JVM的资源消耗。你应该单独问他们。@Peter：我们已经有很多内存，并且已经增加了部分实例的堆。@8472原始问题已经得到了回答，因为似乎没有人认为CPU行为是异常的。接下来的另一个问题是，如何使jvm默认设置“不那么自私”现在看来很明显：将GC调优为只使用一次core max（请参阅）。我们可以在没有pb的情况下暂停几秒钟。幸运的是：）我查看了JavaGC调优链接。它描述了花费CPU而不是允许更长的暂停的范例。另外，从阅读中，我觉得在出现内存不足的情况之前，开销一定很大。Jconsole显示使用的是PS标记扫描GC。它不能解释为什么比典型的四分之一的内核更繁忙（这里是整个盒子）。对我来说，（sys？）调用似乎消耗了大量cpu，而不是GC本身，至少visualvm中的图形暗示了这一点。我现在设置-XX:+UseSerialGC，并减少堆，稍后将看到。您的答案包含错误信息。a） 内部JVM结构不是java对象堆的一部分。默认情况下，在64位JVM上使用最大堆大小<32GB的压缩指针，使其不大于32位版本上的压缩指针。@8472使用meme。。。[需要引证]我很乐意接受更正，但如果要进行更正，请以与我相同的方式提供来源。