Question

我们在DC / OS中的另一个Marathon（MoM）上运行Marathon。

群集相对较小，大约有40个节点和400个正在运行的任务。我很惊讶Marathon没有任何GC配置。在Marathon实例成为领导者后，内存使用量大幅增长。特别是在处理资源提供期间。

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

我们正在使用Marathon 1.5.3。

相关问题：

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：

Concurrent Mark Sweep（CMS）收集器专为需要更短垃圾收集暂停且能够在应用程序运行时与垃圾收集器共享处理器资源的应用程序而设计。
-XX:+UseParNewGC禁用自动启用CMS的并行年轻代GC。
-XX:ParallelGCThreads=2线程由计算机上可用的逻辑处理器数量自动设置。这使GC效率低下，特别是在物理机具有12（或甚至更多）内核且您在Mesos中限制CPU的情况下。应该等于分配给Marathon的cpus的数量。
-XX:+UseCMSInitiatingOccupancyOnly阻止使用一组启发式规则来触发垃圾回收。这将使GC不太可预测，并且通常会延迟收集，直到老一代几乎被占用。提前启动GC允许在旧一代充满之前完成收集，从而避免完整GC（即停止世界暂停）。
-XX:CMSInitiatingOccupancyFraction=80应在触发CMS时通知Java VM。基本上，它允许在堆中创建缓冲区，可以填充数据，而CMS正在工作。 70-80似乎是合理的价值。如果该值太小，GC将频繁触发，如果它太大，GC将被触发太晚。
-XX:MaxTenuringThreshold=1限制将对象复制到旧代池。 CMS的默认值为4。
-XX:+UseCGroupMemoryLimitForHeap -XX:+UnlockExperimentalVMOptions堆将根据cgroups设置进行设置，如果我们不设置-Xmx1536m则非常有用。这两个标志都需要Java 8（目前使用的是mesosphere/marathon Docker镜像）。

我们目前正在使用的马拉松配置：

 "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行为：

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

1 个答案: