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

Question

当从 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 会尝试不惜一切代价避免“堆外”情况:

• 当堆使用量达到“上限”(比配置的最大大小低约 70MB)时，可视化虚拟机显示高 cpu(主要是与 GC 无关的 CPU!)。
• 确实，增加堆大小后 -> 高 cpu 症状消失了。

虽然我知道解决方法，但我在此处输入的目标是两件事:

• 有人能证实这个假设吗？
• 详细了解 jvm 正在做什么及其原因 - 它是 v8/64Bit/windows 特定的吗？
• 如何调整 jvm 行为不影响其他进程(我们在服务器上有超过 50 个实例)，而是放弃、耗尽内存然后死亡(我们有可用性监控并可以跟进)？

提前致谢

Answer 1

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

由于我们有许多 jvm 正在运行，我们不希望在其中一个内存不足时影响所有其他 jvm。解决方案是使用单线程GC:-XX:+UseSerialGC(并限制元空间-XX:MaxMetaspaceSize=512m)。从那时起——大约一年前——jvm 表现良好。jvm 的默认设置似乎是为了单独在服务器上而调整的