Spark应用程序杀死执行者

Question

我正在以独立模式运行 spark 集群，并使用 spark-submit 运行应用程序。在 spark UI 阶段部分，我发现执行阶段的执行时间较长（> 10 小时，通常时间约为 30 秒）。阶段有许多失败的任务，错误为Resubmitted (resubmitted due to lost executor)。在舞台页面的Aggregated Metrics by Executor 部分中有地址为CANNOT FIND ADDRESS 的执行者。 Spark 尝试无限地重新提交此任务。如果我终止这个阶段（我的应用程序会自动重新运行未完成的 spark 作业），那么一切都会继续正常工作。

我还在火花日志中发现了一些奇怪的条目（与阶段执行开始同时）。

大师：

16/11/19 19:04:32 INFO Master: Application app-20161109161724-0045 requests to kill executors: 0
16/11/19 19:04:36 INFO Master: Launching executor app-20161109161724-0045/1 on worker worker-20161108150133
16/11/19 19:05:03 WARN Master: Got status update for unknown executor app-20161109161724-0045/0
16/11/25 10:05:46 INFO Master: Application app-20161109161724-0045 requests to kill executors: 1
16/11/25 10:05:48 INFO Master: Launching executor app-20161109161724-0045/2 on worker worker-20161108150133
16/11/25 10:06:14 WARN Master: Got status update for unknown executor app-20161109161724-0045/1

工人：

16/11/25 10:06:05 INFO Worker: Asked to kill executor app-20161109161724-0045/1
16/11/25 10:06:08 INFO ExecutorRunner: Runner thread for executor app-20161109161724-0045/1 interrupted
16/11/25 10:06:08 INFO ExecutorRunner: Killing process!
16/11/25 10:06:13 INFO Worker: Executor app-20161109161724-0045/1 finished with state KILLED exitStatus 137
16/11/25 10:06:14 INFO Worker: Asked to launch executor app-20161109161724-0045/2 for app.jar
16/11/25 10:06:17 INFO SecurityManager: Changing view acls to: spark
16/11/25 10:06:17 INFO SecurityManager: Changing modify acls to: spark
16/11/25 10:06:17 INFO SecurityManager: SecurityManager: authentication disabled; ui acls disabled; users with view permissions: Set(spark); users with modify permissions: Set(spark)

网络连接没有问题，因为worker，master（上面的日志），驱动程序在同一台机器上运行。

Spark 版本 1.6.1

Answer 1

日志中有趣的部分可能是这样的：

16/11/25 10:06:13 INFO Worker: Executor app-20161109161724-0045/1 finished with state KILLED exitStatus 137

Exit 137 强烈建议存在资源问题，无论是内存还是 cpu 内核。 鉴于您可以通过重新运行该阶段来解决您的问题，可能是所有内核都已被分配（也许您还运行了一些 Spark shell？）。 这是独立 Spark 设置（一台主机上的所有内容）的常见问题。

无论哪种方式，我都会按顺序尝试以下操作：

1. 提升存储内存派系spark.storage.memoryFraction，为存储预分配更多内存，防止系统OOM杀手在大舞台上随机给你137。
2. 为您的应用程序设置较少的内核数，以排除在运行阶段之前预先分配这些内核的情况。您可以通过spark.deploy.defaultCores 执行此操作，将其设置为 3 甚至 2（在英特尔四核上假设 8 个 vcore）
3. 直接为 Spark 分配更多 RAM -> spark.executor.memory 需要增加。
4. 也许您在这里遇到了元数据清理问题，在本地部署中也并非闻所未闻，在这种情况下，将
   export SPARK_JAVA_OPTS +="-Dspark.kryoserializer.buffer.mb=10 -Dspark.cleaner.ttl=43200" 添加到末尾您的spark-env.sh 可能会通过强制元数据清理来解决问题更频繁地运行

在我看来，其中一个应该可以解决问题。

Answer 2

Armin 的回答非常好。我只是想指出什么对我有用。

当我增加参数时，同样的问题消失了：

spark.default.parallelism 从 28（这是我拥有的执行程序的数量）到 84（这是可用内核的数量）。

注意：这不是设置此参数的规则，这只是对我有用的。

更新：这种方法也得到Spark's documentation的支持：

有时，你会得到一个 OutOfMemoryError 不是因为你的 RDD 不适合内存，而是因为你的一个任务的工作集，比如 groupByKey 中的一个 reduce 任务，太大了。 Spark 的 shuffle 操作（sortByKey、groupByKey、reduceByKey、join 等）在每个任务中构建一个哈希表来执行分组，这通常可能很大。 这里最简单的解决方法是提高并行度，使每个任务的输入集更小。 Spark 可以有效地支持短至 200 毫秒的任务，因为它在多个任务中重用了一个执行器 JVM，并且它具有较低的任务启动成本，因此您可以安全地将并行度提高到超过集群中的核心数量。