[英]Spark application kills executor
我在独立模式下运行spark集群,使用spark-submit运行应用程序。 在火花UI阶段我发现执行阶段有大的执行时间(> 10h,通常时间~30秒)。 阶段有许多失败的任务,错误Resubmitted (resubmitted due to lost executor)
。 在阶段页面中Aggregated Metrics by 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版
可能日志中有趣的部分是这样的:
16/11/25 10:06:13 INFO Worker: Executor app-20161109161724-0045/1 finished with state KILLED exitStatus 137
退出137
强烈建议资源问题,内存或CPU内核。 鉴于您可以通过重新运行阶段来解决问题,可能是某些核心已经分配(也许您还运行了一些Spark shell?)。 这是独立Spark设置的常见问题(一台主机上的所有内容)。
无论哪种方式,我都会按顺序尝试以下事项:
spark.storage.memoryFraction
以预先分配更多内存用于存储,并防止系统OOM杀手在大舞台上随机提供137
。 spark.deploy.defaultCores
执行此spark.deploy.defaultCores
,将其设置为3或甚至2(在假设8个vcores的intel四核上) spark.executor.memory
需要上升。 export SPARK_JAVA_OPTS +="-Dspark.kryoserializer.buffer.mb=10 -Dspark.cleaner.ttl=43200"
到最后你的spark-env.sh
可以通过强制元数据清理更频繁地运行来解决这个问题 在我看来,其中一个应该成功。
阿明的答案非常好。 我只想指出对我有用的东西。
当我增加参数时,同样的问题就消失了:
spark.default.parallelism
从28(这是我拥有的执行程序的数量)到84(这是可用核心的数量)。
注意:这不是设置此参数的规则,这只适用于我。
更新 :此方法也得到Spark的文档支持:
有时候,你会得到一个OutOfMemoryError,不是因为你的RDD不适合内存,而是因为你的一个任务的工作集,例如groupByKey中的一个reduce任务,太大了。 Spark的shuffle操作(sortByKey,groupByKey,reduceByKey,join等)在每个任务中构建一个哈希表来执行分组,这通常很大。 这里最简单的解决方法是增加并行度,以便每个任务的输入集更小。 Spark可以有效地支持短至200毫秒的任务,因为它在许多任务中重用了一个执行程序JVM,并且它具有较低的任务启动成本,因此您可以安全地将并行度提高到超过群集中的核心数。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.