我应该设置 MaxMetaspaceSize 吗？答案

【问题标题】：Should I set a MaxMetaspaceSize?我应该设置 MaxMetaspaceSize 吗？
【发布时间】：2015-10-05 23:36:32
【问题描述】：

所以，在问了this 的问题之后，很快就发现重要的问题不是“我该怎么做”，而是“我应该”吗？

我们的客户正在从 Java7 迁移到 Java8（使用 Tomcat7）。 Java7 需要设置-XX:MaxPermSize，一些客户根据个人需求和用途将其最大值增加到安装程序设置的默认值以上。

我应该为已定义自定义最大值的客户设置-XX:MaxMetaspaceSize（之前的-XX:MaxPermSize 设置）吗？新安装呢？我们应该设置-XX:MaxMetaspaceSize 吗？

这样的决定有什么利弊？

【问题讨论】：

我明白，默认情况下，元空间是没有限制的。但是现在它在本机内存中，如果不设置限制，则有可能消耗所有系统内存。更好的是，我的应用程序抛出 OOM 或系统崩溃（没有明显的原因）？当系统崩溃从来没有风险时，通过添加 MaxMetaspaceSize 是否会增加 OOM 崩溃的可能性？
我会设置一个足够大的最大值，在正常情况下不会触发。我这么说的原因是，如果本机内存耗尽或发生疯狂交换，系统可能会表现得非常不稳定且难以控制。比 OOM 或 Java 冻结更糟糕。例如使用 2GB（期望系统至少有 2GB 的可用缓冲区）
@eckes 你能把它移到答案部分吗？值得考虑。
不是--XX:MaxMetaspaceSize，而是-XX:MaxMetaspaceSize。只有一个 - 在 XX 之前

标签： tomcat memory-management java-8

【解决方案1】：

@eckes cmets 的回答：

我会设置一个足够大的最大值，不会在正常情况下触发情况。我这么说的原因是，一个系统可能会非常如果本机内存耗尽或疯狂，则不稳定且难以控制交换发生。比 OOM 或 Java 冻结要糟糕得多。例如使用 2GB（期望系统至少有 2GB 可用缓冲区）

【讨论】：

我在我们的一个 UAT 环境中遇到了本机内存泄漏的问题。我们永远无法从这种情况中恢复，唯一的解决方案是硬重启。

【解决方案2】：

只是为了表达相反的意见，可以使案例始终设置 MaxMetaspaceSize。将世界上的整个应用程序集分成 10 个（二进制 - 考虑一下）组可以讨论原因。但请记住，设置限制仅控制该空间的垃圾收集 (GC) 何时发生。

第 01 组：具有所有非动态类的应用程序

该组将您带入上述稳定带。在这种情况下，要设置的大小相当容易确定（就像 MaxPermSize 一样），而且不会有太多（如果有的话）GC。

第 10 组：具有动态类的应用程序

鉴于功能强大的第三方库的激增，该组中的几乎每个应用程序不都一样吗？通常你不关心这个库是否是 Scala/Groovy/etc，它只是做你想要的，所以它被使用了。用一堆死（动态）类填充元空间的价值是什么？当 GC 确实到来时，它会很昂贵。我宁愿限制大小，让 GC 更频繁（但每个暂停时间更少），更轻松地在同一硬件上运行多个应用程序，而不必担心它们各自的元空间会相互冲突。

【讨论】：

【解决方案3】：

正如我对上一个答案的评论，对这些内存池设置限制的原因是不同的。

如果您的用户之前增加 MaxPermSize 高于默认值，这可能是为了避免使用 CMS 的 Full GC/并发模式失败，或者因为他们的应用程序确实需要大量 perm gen 空间。

将元空间限制从其有效的无限默认值降低将用于完全不同的目的：避免无限制的元空间增长。

问题是这只是一个上限。实际提交的，即 current 元空间大小会更小。事实上，有一个设置叫做MaxMetaspaceFreeRatio（默认70%），这意味着实际的元空间大小永远不会超过其占用率的230%。

为了让它增长，它首先必须填满，强制垃圾收集（元空间已满）以尝试释放对象，并且只有当它不能满足其 MinMetaspaceFreeRatio（默认 40%）目标时，它才会扩展当前元空间在 GC 周期后不超过 230% 的占用率。

因此，在实践中，实际元空间大小应稳定在与其实际需求相近的范围内，除非应用程序不断泄漏类加载器/类或生成大量动态代码。

TL;DR：可能有限制元空间大小的原因，但它们可能与设置 perm gen 大小的原始原因不同。因此需要重新评估。

【讨论】：