OOM 的 Spark 内存管理答案

【问题标题】：Spark Memory Management for OOMOOM 的 Spark 内存管理
【发布时间】：2018-07-10 00:17:51
【问题描述】：

情况如下：我启动了一个 spark 作业，但由于 OOM 的许多任务失败而失败。所以我增加了任务的内存分配。我仍然看到一些节点因 OOM 失败，但这项工作最终可能会成功。我的问题是 Spark 如何处理这个问题？似乎 Spark 可以在尝试失败后重新分配数据。附言失败的任务是在批处理作业中应用Window and Rank 操作。

更新：我在 YARN 集群模式下运行批处理作业。所有任务都配置为具有相同的内存。

【问题讨论】：

所有节点的内存量都一样吗？您使用的是 YARN 还是 Standalone？
@cricket_007 所有节点都有相同的内存。我在 YARN 集群模式下运行作业。
您可以增加执行程序内存，但您仍然受到纱线容器大小和所有其他进程在任何给定机器上消耗内存的限制
@cricket_007 内存在纱线容器大小的限制范围内。我的好奇心是在同一个作业运行中，某些任务可以在某些执行器上成功，但在其他执行器上失败
正如我所说，您需要考虑在集群中其他机器上运行的非 Spark 应用程序

标签： apache-spark hadoop-yarn

【解决方案1】：

Spark DAGScheduler 构建任务阶段并将任务提交给 TaskScheduler 以运行任务。 TaskScheduler 在 executors 上启动任务并将失败的任务重新运行到不同的 executors 并报告给 DAGScheduler。您可以控制次数，放弃之前要重试的任务是 spark.task.maxFailures。默认值为 4。

spark config

请使用重新分区或增加执行器内存以避免重新运行任务。

【讨论】：

感谢您的回答。我知道 Spark 中失败任务的重试。让我感到困惑的是，例如，任务A 在执行器E1 上失败，但后来当A 再次被调度时，它可能在另一个执行器上成功，即使所有执行器都配置了相同的内存。
大卫，可能数据洗牌较少，请检查任务的数据局部性级别。失败的可能是需要从另一个节点进行数据洗牌，而成功的任务可能在分区所在的同一节点上运行。
我检查了失败的任务，locality级别都是PROCESS_LOCAL

【解决方案2】：

Spark 肯定会在其他一些执行器上重试失败的任务，但最多有有限的配置时间。如果您遇到超过 10% 或 20% 的 OOM 任务，这实际上意味着您分配的内存太少，或者每个分区包含太多需要处理的数据。对于后面的原因，您需要将数据分配到更小的分区中。

【讨论】：