Sun JVM 能否毫无问题地处理巨大的堆大小，以及如何处理？

performance heap-memory garbage-collection java jvm

2022-09-03 12:22:01

我听说过几个人声称你不能扩展JVM堆大小。我听说过实际限制是4千兆字节（我听到IBM顾问这么说），10千兆字节，32千兆字节，依此类推......我简直不敢相信这些数字中的任何一个，并且已经对这个问题有一段时间了。

所以，我有三部分问题，我希望有经验的人可以回答：

在以下情况下，您将如何调整堆和 GC 设置？
最终用户是否会注意到明显的小动作（JVM的暂停等）？
这真的应该仍然有效吗？我认为应该这样做。

具体案例：

64 位平台
64 核
64 GB 内存
应用程序服务器面向客户端（即。Jboss/tomcat Web 应用程序服务器） - 最终用户可能会注意到 JVM 的完全暂停
Sun JVM，可能是 1.5

为了证明我不是要求你们做我的功课，这就是我想到的：

-XX:+UseConcMarkSweepGC -XX:+AggressiveOpts -XX:+UnlockDiagnosticVMOptions -XX:-EliminateZeroing -Xmn768m -Xmx55000m
CMS应该减少暂停量，尽管它会带来开销。CMS的其他设置似乎自动默认为CPU的数量，因此它们对我来说似乎是理智的。我添加的其余部分是额外的功能，这些附加功能通常对性能有好处或坏处，它们可能应该进行测试。
绝对。

答案 1

我认为，如果没有对你的应用有进一步的了解，任何人都很难给你提供除了一般建议之外的任何东西。

我建议你使用VisualGC（或VisualVM的VisualGC插件）来实际查看垃圾回收在你的应用程序运行时正在做什么。一旦您更好地了解了 GC 如何与应用程序一起工作，调整它就会容易得多。

答案 2

#1.在以下情况下，您将如何调整堆和 GC 设置？

首先，拥有 64 GB 的内存并不意味着您必须将它们全部用于一个 JVM。实际上，这意味着您可以运行其中的许多。然后，如果不访问您的机器和应用程序来测量和分析事物，就不可能回答您的问题（仅知道您的应用程序正在做什么是不够的）。不，我不是要求访问您的环境:)

#2.最终用户是否会注意到明显的小动作（JVM的暂停等）？

调谐的目标是在（主要）GC的频率和持续时间之间找到一个很好的折衷方案。对于~55g堆，GC不会频繁，但肯定会花费明显的时间（堆越大，主要GC越长）。使用并行或并发垃圾回收器将有助于多处理器系统，但不能完全解决此问题。为什么你需要~55g（这对于Webapp IMO来说是超级巨大的），这就是我的问题。如果需要，我宁愿运行许多集群JVM来处理负载（在某些时候，对于面向数据的应用程序，数据库无论如何都会成为瓶颈）。

#3.这真的应该仍然有效吗？我认为应该这样做。

嗯。。。不确定我是否得到这个问题。什么是“这个”？实例化一个大堆的JVM？是的，它应该。它是否等同于运行多个 JVM？不，当然不是。

PS：4G 是在 64 位操作系统上运行的 32 位 JVM 的最大理论堆限制（请参阅为什么我无法使用 32 位 JVM 获得更大的堆？)

PPS：在 64 位 VM 上，您有 64 位的可寻址性可供使用，因此最大 Java 堆大小仅受系统提供的物理内存量和交换空间的限制。（请参阅使用 64 位 VM 可以创建多大的堆？)