我想知道当cgroup被启用时，spark在mesos上的细粒度模式的行为会是什么。
一个问题是，当我在没有cgroups的情况下使用mesos+spark时，它已经表明实际的spark executor进程使用的内存至少比它向mesos承诺使用的多10%。当启用cgroup时，它会杀死spark执行器吗？
第二，如何处理文件缓存？spark严重依赖于文件缓存。文件缓存占mesos的内存量吗？可能不会，但我们能影响这个吗？例如，理想情况下，我希望spark总共使用8gb，其中5gb应该用于java进程——假设spark运行良好，并且不会超过5gb——而3gb应该用作文件缓存（max）。
我希望有人有这方面的经验，因为为了亲自测试这些东西，我必须经历来自集群系统管理员的大量支持请求，因为cgroups在某一点上依赖于根凭据—我讨厌没有请求其他人就白费力气。
1条答案
按热度按时间qc6wkl3g1#
回答你的第一个问题，似乎你对cgroups的工作方式有些混淆。执行器根本无法分配比cgroups所允许的内存更多的内存。所以mesos实际上不会充当进程杀手之类的。但是，某些类型的程序确实会因为无法分配更多的内存而中断，这取决于程序是否退出，或者是否能够正常运行，但可能内存和/或性能更少。
对于第二个问题，似乎没有任何配置设置来影响实际的cgroup内存量。在executor内存设置和spark从mesos得到什么之间似乎有一个1:1的Map。不过，我确实认为有一个隐藏的因素，因为我可以看到spark要求大约5.8gb，但实际上我将executor内存设置为5gb(一旦我能在源代码中找到15%的隐藏因子，我就会更新票据。）
更新，你想要的设置是
spark.mesos.executor.memoryOverhead. 您可以给出一个以兆字节为单位的数字，它被添加到executor内存中，作为将用作mesos资源的总内存，从而作为cgroup内存限制。memory.oom_control在/cgroups/memory/x/设置为“0”（计数器直观地启用）。然而，在Spark的情况下，它是上述10-15%的开销，这给了足够的余地，不会遇到oom。