EMR-5.32.0上的Spark未生成请求的执行器 [英] Spark on EMR-5.32.0 not spawning requested executors

问题描述

我在EMR(版本5.32.0)上的(Py)Spark中遇到了一些问题。大约一年前，我在EMR集群上运行了相同的程序(我认为发行版一定是5.29.0)。然后，我能够使用spark-submit参数正确配置我的PySpark程序。但是，现在我正在运行相同/相似的代码，但是spark-submit参数似乎没有任何效果。

我的集群配置：

• 主节点：8个VCORE，32 GiB内存，仅EBS存储EBS存储：128 GiB
• 从节点：10 x 16 VCORE，64 GiB内存，仅EBS存储EBS存储：256 GiB

我使用以下spark-submit参数运行该程序：

spark-submit --master yarn --conf "spark.executor.cores=3" --conf "spark.executor.instances=40" --conf "spark.executor.memory=8g" --conf "spark.driver.memory=8g" --conf "spark.driver.maxResultSize=8g" --conf "spark.dynamicAllocation.enabled=false" --conf "spark.default.parallelism=480" update_from_text_context.py

我没有更改群集上的默认配置中的任何内容。

下面是Spark UI的屏幕截图，其中只显示了10个执行器，而我预计会有40个执行器可用...

我尝试了不同的spark-submit参数，以确保错误与Apache Spark: setting executor instances does not change the executors无关。我试了很多方法，但似乎都没有用。

我有点迷路了，有人能帮帮忙吗？

更新： 我在EMR版本标签5.29.0上运行了相同的代码，在那里spark-submit参数中的conf设置似乎产生了影响：

为什么会发生这种情况？

推荐答案

很抱歉造成混淆，但这是故意的。在EMR-5.32.0上，Spark+Year将把登陆同一节点的多个执行器请求合并到一个更大的执行器容器中。请注意，即使您的执行器比您预期的要少，但是每个执行器都有您指定的更多的内存和核心。(不过，这里有一个星号，我将在下面解释。)

在大多数情况下，默认情况下，此功能旨在提供更好的性能。如果您确实希望保留以前的行为，您可以通过设置spark.yarn.heterogeneousExecutors.enabled=false，来禁用此新功能，尽管我们(我是电子病历团队的成员)希望听取您的意见，说明为什么使用以前的行为更可取。

但是，有一件事对我来说是不合理的，那就是您最终应该拥有与没有此功能时相同的Executor核心总数，但对于您分享的示例似乎没有发生这种情况。您需要40个执行器，每个执行器有3个核心，但后来得到了10个执行器，每个执行器有15个核心，这总共有点多。这可能与您所请求的5G内存划分为您选择的实例类型上的可用内存的方式有关，我猜这可能是m5.4xLarge。有一件事可能会对您有所帮助，那就是删除您对spak.ecutor.memory/core/insties的所有覆盖，只使用缺省值。我们希望，在大多数情况下，默认设置将提供最佳性能。如果没有，就像我上面说的，请让我们知道，这样我们就可以进一步改进！

这篇关于EMR-5.32.0上的Spark未生成请求的执行器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！