java - 内存中的大型对象的 JVM 问题

Question

我有一个包含短字符串列表的二进制文件，它在启动时加载并作为从字符串到 protobuf(包含字符串..)的映射存储在内存中。 (不理想，但由于遗留问题很难更改该设计)最近，该列表从 ~2M 增加到 ~20M 条目，导致它在构建 map 时失败。

首先我得到了 OutOfMemoryError: Java heap space。

当我使用 xms 和 xmx 增加堆大小时，我们遇到了 GC overhead limit exceeded。

在具有 15GB 可用内存和以下 JVM args 的 Linux 64 位机器上运行(我增加了 RAM 10G->15G 和堆标志 6000M -> 9000M):

-Xms9000M -Xmx9000M -XX:PermSize=512m -XX:MaxPermSize=2018m

这个二进制文件做了很多事情，并且正在为实时流量提供服务，所以我不能承受它偶尔被卡住的后果。

编辑:我最终做了一件显而易见的事情，即修复代码(从 HashMap 更改为 ImmutableSet)并添加更多 RAM (-Xmx11000M)。

Answer 1

I'm looking for a temporary solution if that's possible until we have a more scalable one.

首先，您需要确定“OOME:超出 GC 开销限制”是否是由于堆:

• 太小...导致 JVM 重复 Full GC，或者

• 太大...导致 JVM 在运行 Full GC 时破坏虚拟内存。

您应该能够通过打开和检查 GC 日志来区分这两种情况，并使用操作系统级别的监控工具来检查过度的分页负载。 (在检查分页级别时，还要检查问题是否是由于您的 JVM 和另一个耗费大量内存的应用程序之间对 RAM 的竞争造成的。)

如果堆太小，请尝试将其变大。如果太大，请将其变小。如果您的系统同时显示这两种症状……那么您就有大问题了。

您还应该检查您的 JVM 是否启用了“压缩 oops”，因为这会减少 JVM 的内存占用。 -XshowSettings 选项列出 JVM 启动时生效的设置。如果压缩 oops 被禁用，请使用 -XX:+UseCompressedOops 启用它们。

(您可能会发现默认情况下启用压缩 oops，但值得检查。这将是一个简单的修复...)

如果以上方法都不起作用，那么您唯一的快速解决方法就是获取更多 RAM。

---

但显然，真正的解决方案是重新设计代码，这样您就不需要庞大的(并且会随着时间的推移而增加)内存中数据结构。