Spark应用程序杀死执行者

Question

我在独立模式下运行spark集群，应用程序使用spark-submit。在spark UI阶段部分，我发现执行阶段的执行时间很长(> 10h，通常时间约为30秒)。阶段有许多失败的任务，错误为Resubmitted (resubmitted due to lost executor)。阶段页的Aggregated Metrics by Executor部分中有地址为CANNOT FIND ADDRESS的executor。Spark尝试无限地重新提交此任务。如果我结束了这个阶段(我的应用程序自动重新运行未完成的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

退出137强烈建议资源问题，无论是内存还是cpu核心。假设你可以通过重新运行stage来修复你的问题，那么可能是所有的内核都已经被分配了(也许你也有一些Spark shell在运行？)这是独立Spark设置的常见问题(所有内容都在一台主机上)。

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

1. 提高了存储内存功能spark.storage.memoryFraction，以预先分配更多的内存用于存储，并防止系统对象模型杀手在大舞台上随机给你该137。
2. 为你的应用程序设置了较低的核心数量，以排除在你的阶段运行之前预先分配这些核心的可能性。您可以通过spark.deploy.defaultCores完成此操作，将其设置为3甚至2(在英特尔四核上，假设8 vcores)
3. Outright分配更多内存给Spark -> spark.executor.memory需要增加内存。
4. 您可能会在这里遇到元数据清理问题，在本地部署中也不是没有听说过，在这种情况下，添加

通过强制元数据清理更频繁地运行，您的spark-env.sh可能会完成此任务

在我看来，其中一个应该能起到作用。

Answer 2

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

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

spark.default.parallelism从28 (这是我拥有的执行器的数量)到84 (这是可用的核心数量)。

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

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

有时候，你会得到一个OutOfMemoryError，不是因为你的RDDs放不下内存，而是因为你的一个任务的工作集太大了，比如groupByKey中的reduce任务之一。Spark的混洗操作(sortByKey、groupByKey、reduceByKey、join等)在每个任务中构建一个哈希表来执行分组，分组通常很大。这里最简单的解决方法是提高并行级别，以便每个任务的输入集更小。 Spark可以有效地支持短至200ms的任务，因为它在许多任务中重用了一个executor JVM，并且任务启动成本很低，因此您可以安全地将并行级别提高到超过集群中的核心数量。