使用cgroups作为Spark时介观分子的行为

Question

我想知道当cgroups被启用时，Spark在Mesos的细粒度模式下的行为会是什么。

一个问题是:当我在不使用cgroup的情况下使用Mesos+spark时，它已经表明实际的spark executor进程使用的内存至少比它承诺的Mesos使用的内存多10%。当启用cgroup时，会杀死Spark-executors吗？

其次，文件缓存是如何处理的？Spark严重依赖于文件缓存。文件缓存是否计入Mesos中的内存量？可能不会，但我们能影响到这一点吗？例如，理想情况下，我希望Spark总共使用8 3GB，其中5 3GB应该用于java进程--假设spark运行得很好，并且不超过5 3GB-3 3GB应该用作文件缓存(max)。

我希望有人有这方面的经验，因为为了亲自测试这些东西，我将不得不经历我们的集群sysadmin的许多支持请求，因为cgroup在某一点上依赖于root凭据-我不喜欢在没有询问其他人的情况下徒劳无功。

Answer 1

要回答你的第一个问题，看起来你把cgroup的工作方式搞混了。executor不会(我可以确认，它确实会)能够分配比cgroup所允许的更多的内存。因此，Mesos实际上不会充当进程杀手或其他什么*。但是，某些类型的程序确实会因为无法分配更多的内存而中断，这取决于程序是否退出，或者能够正常运行，但可能具有较少的内存和/或性能。

对于你的第二个问题，似乎没有任何配置设置来影响实际的cgroup内存量。在executor内存设置和Spark从Mesos获得的内容之间似乎存在一对一的映射关系。然而，我确实认为有一个隐藏的因素，因为我可以看到Spark要求大约5.8 5GB的内存，但实际上我将executor的内存设置为5 5GB。(一旦我在源代码中找到这个可能占15%的隐藏因素，我就会更新票证。)

更新，您需要的设置是spark.mesos.executor.memoryOverhead。您可以在MegaBytes中指定一个数字，该数字将作为总内存添加到executor内存中，该总内存将用作Mesos资源，从而作为cgroup内存限制。

实际上，*=Update2在默认情况下确实会杀死超出控制组限制的进程。我可以确认/cgroups/memory/x/中的memory.oom_control设置为'0‘(这与直觉相反)。然而，在Spark的情况下，正是上述10-15%的开销给了足够的回旋余地，使其不会遇到OOM。