使用Amazon的“maximizeResourceAllocation”设置的Spark + EMR不使用所有内核/核心

我正在为Spark使用亚马逊特定的maximizeResourceAllocation标志（如记录here）运行EMR集群（版本emr-4.2.0）。根据这些文档，“该选项计算核心节点组中节点上执行程序可用的最大计算和内存资源，并使用此信息设置相应的spark-defaults设置”。使用Amazon的“maximizeResourceAllocation”设置的Spark + EMR不使用所有内核/核心

我使用m3.2xlarge实例为工作节点运行群集。我为YARN master使用了一个单独的m3.xlarge - 我可以运行它的最小m3实例，因为它没有太多的工作。

情况是这样的：当我运行一个Spark作业时，每个执行程序请求的内核数为8个（配置为"yarn.scheduler.capacity.resource-calculator": "org.apache.hadoop.yarn.util.resource.DominantResourceCalculator"后我才得到这个，但实际上并没有在文档中，但我离题了）。这似乎是有道理的，因为根据these docs m3.2xlarge有8“vCPU”。但是，在实际实例本身中，在/etc/hadoop/conf/yarn-site.xml中，每个节点都配置为yarn.nodemanager.resource.cpu-vcores设置为16。我会（猜测）认为这一定是由于超线程或其他一些硬件的幻想。

所以问题是这样的：当我使用maximizeResourceAllocation时，我得到了Amazon Instance类型所具有的“vCPU”数量，这似乎只是YARN运行在配置“VCores”数量的一半节点;因此，执行程序仅使用实例上实际计算资源的一半。

这是Amazon EMR中的错误吗？其他人是否遇到同样的问题？是否还有其他一些我没有记录的魔法无证配置？

来源

2015-11-30 retnuH

通过这个设置，你应该得到的每个实例（除主）1个执行人，每8个内核和有关的RAM 30GB。

http：//：8088处的Spark UI未显示该分配？

我不知道该设置确实是一个很大的值进行比较，该网页上提到的其他一个“启用执行人的动态分配”。这将让Spark管理它自己的一个工作实例数量，如果您为每个执行器启动一个任务，其中包含2个CPU核心和3G内存，则EMR实例大小的CPU与内存的比例会相当不错。

来源

2015-11-30 17:12:23

它确实表明：但问题在于那些“8”核心实际上只有YARN分配的16个“VCores”中的8个;机器上一半的实际CPU资源将闲置。由于我试图运行CPU密集型作业，这显然是CPU浪费（和钱）。） – retnuH

核心只是实例类型本身的抽象。没有实际的内核绑定，因此执行程序将使用尽可能多的CPU应用程序请求。使用DominantResourceCalculator作为调度程序时唯一的绑定来了。需要注意的一点是，此实例类型的EMR默认配置是vcore值的两倍，以告知纱线以帮助提高MapReduce的CPU利用率。 maximizeResourceAllocation正在查看实例类型核心定义。 – ChristopherB

好，很多实验后，我能够追查问题。我要在这里报告我的发现，以帮助人们避免在未来受挫。

虽然8个核心需求与YARN知道的16个VCore之间存在差异，但这似乎没有什么差别。 YARN没有使用cgroups或任何奇怪的东西来实际限制执行程序实际使用的CPU数量。
执行器上的“Cores”实际上有点用词不当。实际上，执行者在任何时候都愿意运行多少个并发任务;基本上归结为每个执行器上有多少线程正在“工作”。
当maximizeResourceAllocation设定，当您运行星火计划，它设置属性spark.default.parallelism为实例内核（或“虚拟CPU”）的所有非主实例是那样的集群在时数创建。即使在正常情况下，这可能太小了;我听说，建议将其设置为核心数量的四倍，以便运行作业。这将有助于确保在任何给定阶段有足够的任务可用来保持所有执行程序中的CPU繁忙。
如果您的数据来自不同运行的不同火花程序，则您的数据（采用RDD或Parquet格式或其他）很可能会通过不同数量的分区进行保存。运行Spark程序时，请确保您在加载时或在特别CPU密集型任务之前重新分区数据。由于您可以在运行时访问spark.default.parallelism设置，因此这可能是重新分配的方便数字。

TL; DR

maximizeResourceAllocation会为你正确地除了做几乎所有...
你可能想明确设置spark.default.parallelism 4倍实例核心数量，你希望作业在每个“步骤”（在EMR说）/“应用程序”（在YARN说）的基础上运行，即每次设置它和...
确保在您的程序之内您的数据被适当地分区（即想多分区）允许星火并行得当

来源

2015-12-02 11:05:11 retnuH

我想补充一点，使用Spark的动态资源计算也可以在这里使用（http://docs.aws.amazon.com/ElasticMapReduce/latest/ReleaseGuide/emr-spark-configure.html#spark-dynamic-allocation）。此外，用户可以通过虚拟实例类型的虚拟核心来实现每个执行者平衡的每个任务，并具有实际的CPU使用率。 – ChristopherB

在EMR 3.x版

，这maximizeResourceAllocation用参考表来实现：https://github.com/awslabs/emr-bootstrap-actions/blob/master/spark/vcorereference.tsv

它使用一个shell脚本：maximize-spark-default-config，在同样的回购，你可以看看他们是如何实现这一点的。

也许在新的EMR版本4中，这个参考表有点不对......我相信你可以在EMR的EC2实例中找到所有这个AWS脚本，应该位于/usr/lib/spark或/opt/aws或类似的东西。

无论如何，至少，你可以编写自己的脚本bootstrap action这在EMR 4，用正确的参考表，类似于EMR 3.X实施

而且，由于我们要使用STUPS基础，值得我们来看一看STUPS家电为星火：https://github.com/zalando/spark-appliance

你可以明确地通过设置参数指数Senza指定DefaultCores内核的数量，当你部署火花集群

一些该设备比较EMR的亮点是：

能够与连T2实例类型，自动可伸缩的基于像其他STUPS家电角色等

使用它，你可以很容易地部署集群在HA模式与动物园管理员，所以主节点上没有SPOF，EMR中的HA模式目前还不可能，我相信EMR主要是为“临时用于临时分析工作的大型集群”设计的，而不是专用于“专用永久开启的集群“，所以HA模式在EMR附近将不可能实现。

来源

2015-12-02 13:00:31 chutium

使用Amazon的“maximizeResourceAllocation”设置的Spark + EMR不使用所有内核/核心

回答

相关问题