启动后一分钟火花丢失所有执行者

我在默认设置的8节点Google dataproc群集上运行pyspark。启动后几秒钟我看到运行（如预期）30个执行内核：启动后一分钟火花丢失所有执行者

 
    >>> sc.defaultParallelism 
    30

一分钟后：

 
    >>> sc.defaultParallelism 
    2

从这一点所有的动作上只有2个内核上运行：

 

    >>> rng = sc.parallelize(range(1,1000000)) 
    >>> rng.cache() 
    >>> rng.count() 
    >>> rng.getNumPartitions() 
    2

如果我运行rng.cache()核心仍然连接时，他们保持连接和作业分布。

检查监测应用程序（主节点上的端口4040）显示执行人被删除：

Executor 1 
Removed at 2016/02/25 16:20:14 
Reason: Container container_1456414665542_0006_01_000002 exited from explicit termination request."

有一些设置，可以继续使用，无需连接解决方法内核？

来源

2016-02-26 Tomas Vitulskis

大部分情况下，你所看到的实际上只是Yarn上的Spark可以配置与Spark独立的区别。目前，YARN报告的“使用的VCore”实际上并不正确地对应于核心的实际容器预留，而容器实际上仅基于内存预留。

总体有在这里打球几件事情：

动态分配使星火放弃闲置执行人回纱，可惜在那个垃圾无害的，但“失去了执行”的消息瞬间火花印刷品。这是YARN上经典的火花问题，其中火花原本是瘫痪的集群，因为它会抓住它认为需要的最大数量的容器，然后永远不要放弃它。

通过动态分配，当您开始长时间工作时，spark会快速分配新容器（类似于指数斜升，以在几分钟内快速填充完整的YARN集群），并且在空闲时放弃执行器在大约60秒的时间间隔内相同的降速（如果空闲60秒，则放弃一些执行器）。

如果你想停用动态分配，您可以运行：

spark-shell --conf spark.dynamicAllocation.enabled=false 

gcloud dataproc jobs submit spark --properties spark.dynamicAllocation.enabled=false --cluster <your-cluster> foo.jar

另外，如果指定遗嘱执行人的一个固定的数字，它也应该自动停用动态分配：

spark-shell --conf spark.executor.instances=123 

gcloud dataproc jobs submit spark --properties spark.executor.instances=123 --cluster <your-cluster> foo.jar

来源

2016-02-26 12:04:15

如果设置这个值越低，工作是否完成，可能需要更长的时间？换句话说，如果你不使用动态分配，如果他们试图请求比设置更多的执行者，作业会失败吗？ – Davos

启动后一分钟火花丢失所有执行者

回答

相关问题