Spark在启动后一分钟就会丢失所有执行程序

Tom*_*kis 6 apache-spark pyspark google-cloud-dataproc

pyspark使用默认设置在8节点Google dataproc群集上运行.启动后几秒钟我看到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." 
Run Code Online (Sandbox Code Playgroud)

是否有一些设置可以保持核心连接而无需解决方法?

Doi*_*nal 11

在大多数情况下,您所看到的实际上只是可以配置Spark on YARN与Spark独立的差异.目前,YARN报告的"使用过的VCores"实际上并没有正确对应核心的真实容器预留,而容器实际上只是基于内存预留.

总的来说,有一些事情在这里发挥作用:

动态分配导致Spark将空闲执行程序放回YARN,不幸的是,目前spark打印出垃圾邮件但无害的"丢失执行程序"消息.这是YARN上经典的火花问题,火花最初瘫痪了它所运行的星团,因为它会抓住它认为需要的最大数量的容器,然后永远不会放弃它们.

通过动态分配,当你开始一个长时间的工作时,火花快速分配新的容器(像指数上升一样,可以在几分钟内快速填满一个完整的YARN集群),并在空闲时,放弃执行者使用相同的斜坡-down以大约60秒的间隔(如果空闲60秒,放弃一些执行者).

如果要禁用动态分配,可以运行:

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

gcloud dataproc jobs submit spark --properties spark.dynamicAllocation.enabled=false --cluster <your-cluster> foo.jar
Run Code Online (Sandbox Code Playgroud)

或者,如果指定固定数量的执行程序,它还应自动禁用动态分配:

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

gcloud dataproc jobs submit spark --properties spark.executor.instances=123 --cluster <your-cluster> foo.jar
Run Code Online (Sandbox Code Playgroud)