-XX： MaxRAMFraction=1在容器环境中生产安全吗？

Question

Java 8/9带来了对堆的支持（使用代码），XX:UseCGroupMemoryLimitForHeap（解除锁定实验操作）。这将把-XX:MaxRAM设置为cgroup内存限制。默认情况下，JVM分配大约25%的最大RAM，因为默认值为4。

示例：

MaxRAM = 1g
MaxRAMFraction = 4
JVM is allowed to allocate: MaxRAM / MaxRAMFraction = 1g / 4 = 256m

对于（通常）由单个JVM进程组成的部署来说，只使用25%的配额似乎是浪费。所以现在人们设置-XX： MaxRAMFraction=1，所以理论上允许JVM使用100%的MaxRAM。

对于1g示例，这通常会导致堆大小约为900m。这似乎有点高——JVM或其他东西（如远程shell或进程外任务）没有太多的可用空间。

那么，这种配置（XX:UnlockExperimentalVMOptions-XX:UseCGroupMemoryLimitForHeap-XX:MaxRAMFraction=1）是否被认为对产品安全，甚至是最佳做法？或者我还是应该手动选择Xmx、Xms、Xss等等？

Answer 1

最近的oracle-jdk-8（8u191）带来了以下选项，允许Docker容器用户对将用于Java堆的系统内存量进行更细粒度的控制：

-XX:InitialRAMPercentage
-XX:MaxRAMPercentage
-XX:MinRAMPercentage

添加了三个新的JVM选项，以允许Docker容器用户对将用于Java堆的系统内存量进行更细粒度的控制：

-二十： InitialRAMPercentage-XX:MaxRAMPercentage-XX:MinRAMPercentage这些选项替换不推荐使用的分数形式（-XX:InitialRampentage、-XX:MaxRampentage和-XX:MinRampentage）。

看见https://www.oracle.com/technetwork/java/javase/8u191-relnotes-5032181.html

Answer 2

我们做了一些简单的测试，显示设置-XX： MaxRAM=$QUOTA和-XX： MaxRAMFraction=1会导致负载下的死容器。JVM分配了超过900M堆，这太多了。-XX： MaxRAMFraction=2似乎是安全的（ish）。

请记住，您可能希望为其他进程留出空间，例如在容器中获取调试shell（docker exec）或诊断。

编辑：我们已经在一篇文章中详细介绍了所学内容。货币报价：

TL'DR：Java内存管理和配置仍然很复杂。尽管自Java 9/8u131以来，JVM可以读取cgroup内存限制并相应地调整内存使用，但它并不是一颗金弹。您需要知道什么是堆，并且需要为每个部署微调一些参数。否则，您可能会浪费资源和金钱，或者在最坏的时候让您的容器被杀死<代码>-XX:MaxRAMFraction=1特别危险。Java 10带来了很多改进，但仍需要手动配置。为了安全起见，对你的东西进行负载测试。

和

最优雅的解决方案是升级到Java 10。Java 10反对使用组内存限制堆（11），并引入了取代它的容器支持（12）。它还引入了MaxRAMPercentage（13），它的值介于0和100之间。这允许对允许JVM分配的RAM量进行细粒度控制。由于默认情况下启用了UseContainerSupport，因此所有操作都应该是现成的。

编辑#2：我们已经写了更多关于-XX： UseContainerSupport的内容

Java10引入了UseContainerSupport（默认启用），它使JVM在容器环境中使用正确的默认值。自8u191以来，此功能向后移植到Java8，可能允许大量Java部署正确配置其内存。