Marathon 推荐的 Java GC 配置是什么？

Question

我们在 DC/OS 中在另一场马拉松 (MoM) 的基础上运行马拉松。

集群比较小，大概有40个节点，400个运行任务。我很惊讶 Marathon 没有附带任何 GC 配置。 Marathon 实例成为领导者后，内存使用量显着增长。尤其是在处理资源报价时。

我注意到Tomek from Allegro 遇到了类似的问题，但他没有提及任何具体配置。有人有经过实战考验的配置吗？

我们正在使用 Marathon 1.5.3。

相关问题：

• Memory Limit Recommendations for Marathon (MARATHON-3516)
• Document/Enhance Marathon memory behavior (MARATHON-7795)

Answer 1

默认 Java GC 配置不是在容器中运行 Java 应用程序的最佳配置，因为它是 explained in detail by Jörg Schad from Mesosphere。为什么 Mesosphere 不应用建议的配置，它的容器编排器对我来说仍然是个谜。

默认情况下，Java 8 使用 ParallelGC (-XX:+UseParallelGC)。

建议的 Java 标志：

• -Xmx1536m 最大堆大小，取决于您的集群大小（通过 Marathon 运行的任务数）
• -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled 由于响应时间对于集群编排器来说至关重要，因此并发收集器似乎是最合适的。作为documentation says：

  并发标记清除 (CMS) 收集器专为喜欢更短的垃圾收集暂停并且能够在应用程序运行时与垃圾收集器共享处理器资源的应用程序而设计。

• -XX:+UseParNewGC 禁用由 CMS 自动启用的并行年轻代 GC。
• -XX:ParallelGCThreads=2 线程由机器上可用的逻辑处理器数量自动设置。这使得 GC 效率低下，尤其是在物理机具有 12（甚至更多）内核并且您在 Mesos 中限制 CPU 的情况下。应该等于分配给 Marathon 的 cpus 的数量。
• -XX:+UseCMSInitiatingOccupancyOnly 防止使用启发式规则集来触发垃圾收集。这将使 GC 的可预测性降低，并且通常倾向于延迟收集，直到老年代几乎被占用。提前启动 GC 可以在老年代满之前完成收集，从而避免 Full GC（即 stop-the-world 暂停）。
• -XX:CMSInitiatingOccupancyFraction=80 通知 Java VM 何时应该触发 CMS。基本上，它允许在 CMS 工作时在堆中创建一个可以填充数据的缓冲区。 70-80 似乎是合理的价值。过小会频繁触发GC，过大则会过晚触发GC。
• -XX:MaxTenuringThreshold=1 限制复制对象到老年代池。 CMS 的默认值为 4。
• -XX:+UseCGroupMemoryLimitForHeap -XX:+UnlockExperimentalVMOptions 堆将根据cgroups 设置进行设置，如果我们不设置-Xmx1536m 则很有用。 Java 8 需要这两个标志（即当前使用的 mesosphere/marathon Docker 映像）。

这是我们目前使用的 Marathon 配置：

 "cpus": 2,
 "mem": 2304,
 "env": {
        "JVM_OPTS": "-Xms512m -Xmx1536m -XX:+PrintGCApplicationStoppedTime -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseParNewGC -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -XX:MaxGCPauseMillis=200 -XX:MaxTenuringThreshold=1 -XX:SurvivorRatio=90 -XX:TargetSurvivorRatio=9 -XX:ParallelGCThreads=2 "
     },

这是 GC 调整后同一集群上的 Marathon 行为：