Apache spark 启动一分钟后，火花松开所有执行器

我使用默认设置在8节点Google dataproc集群上运行

pyspark

。 启动几秒钟后，我看到30个executor Core正在运行（如预期的那样）：

---

是否有一些设置可以在没有解决办法的情况下保持芯线连接？

在大多数情况下，您看到的实际上只是纱线上的Spark与Spark standalone在配置方式上的差异。目前，Thread报告的“VCores Used”实际上并没有正确地对应于核心的真实容器保留，而容器实际上只是基于内存保留

总的来说，这里有一些因素在起作用：

动态分配导致Spark将空闲的执行器放弃给纱线，不幸的是，此时Spark打印出垃圾但无害的“丢失执行器”消息。这是纱线上火花的经典问题，火花最初会使它运行的簇瘫痪，因为它会抓住它认为需要的最大数量的容器，然后永不放弃

使用动态分配，当您开始一项长期工作时，spark会快速分配新容器（具有指数级爬升功能，可以在几分钟内快速填充整个纱线簇），而在空闲时，spark会以大约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.dynamicAllocation.enabled=false
gcloud dataproc jobs submit spark--properties spark.dynamicAllocation.enabled=false--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

sparkshell--conf spark.executor.instances=123
gcloud dataproc jobs submit spark--properties spark.executor.instances=123--cluster foo.jar

如果您将此值设置得更低，作业是否会完成，可能需要更长的时间？或者换句话说，如果您不使用动态分配，如果作业试图请求比设置更多的执行者，作业是否会失败？@Davos我相信，如果您设置一个固定的数字，Spark不会要求更多。 >>> rng = sc.parallelize(range(1,1000000)) >>> rng.cache() >>> rng.count() >>> rng.getNumPartitions() 2

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

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