AWS EMR 上 Spark 任务 Container killed Exit code 137 错误

一、问题描述

近期,使用 AWS EMR 集群上跑 Spark 任务时常出现 Container killed on request. Exit code is 137 这样的报错信息,导致任务运行失败

报错日志如下:

Caused by: org.apache.spark.SparkException: Job aborted due to stage failure: Task 2 in stage 3.0 failed 4 times, most recent failure: Lost task 2.3 in stage 3.0 (TID 23, ip-xxx-xxx-xx-xxx.compute.internal, executor 4): ExecutorLostFailure (executor 4 exited caused by one of the running tasks) Reason: Container marked as failed: container_1516900607498_6585_01_000008 on host: ip-xxx-xxx-xx-xxx.compute.internal. Exit status: 137. Diagnostics: Container killed on request. Exit code is 137

二、原因分析

看报错日志是因为 container 进程被杀,但是查看每个 executor 的内存使用情况后,发现每个 container 的 gc 时间都很合理,并没有任何 oom 的报错

然后根据丢失节点的 ip 信息找到对应节点的状态,发现其 status 为:dead,整体 gc 时常也很正常,光看日志只能得出一个结论:该任务失败是因为某个节点的 container 因为某个原因被强制停止导致的,这个原因无从下手

后续在 aws 的官网上找到了答案,具体描述如下:

当容器(Spark 执行程序)内存不足时,YARN 会自动将其终止。这会导致“根据要求终止容器。退出代码 137”错误。这些错误可能发生在不同的作业阶段,无论是窄还是宽转换。

说白了,还是内存不足,只不过在日志里查不到什么踪迹

三、解决方案

解决单个 executor 内存不足的方案非常多,大体思路有如下几点:

1,给 executor 加内存

--executor-memory xxg

2,增加数据分区数量

比如,spark 任务里有处理 10g 的数据,对应的 DataFrame 有 10 个分区,那么每个分区就有 1G 的大小,单个 task 处理的数据也就是 1G,这样给 Container 进程的内存带来较大压力

我们可以通过给这种数据进行重分区,比如将其分成 100 个分区,这样每个分区数据就只有 0.1G 了

val numPartitions = 100
val newDF = df.repartition(numPartitions)

3,增加 shuffle 分区数

道理第二点,只不过 spark 在 shuflle 后写出的分区数量是另外一个参数控制,如果不设置默认是 200,该参数配置如下:

//spark sql 中配置参数
spark.sql.shuffle.partitions=500
//使用代码时配置参数
spark.default.parallelism=500

4,减少 core 数量

每个 Container 进程里运行的线程数量越多,消耗的内存也会越大,所以可以通过降低每个 Container 内部运行的线程数来减低 Container 的内存消耗

参数配置如下:

--executor-cores 1

参考链接:退出代码 137 错误

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页