单个多核服务器上的SPARK 2.4独立+多个Worker;提交正在等待资源

时间:2018-12-21 07:29:32

标签: apache-spark pyspark jupyter-notebook apache-spark-standalone

在配备12-Cores64gb-RAM的配备合理的 64位Fedora (家庭)服务器上,我以Spark 2.4模式运行Standalone./spark-env.sh中进行以下配置(未显示该文件中我已注释掉的项目):

# =====================================================================
# Options for the daemons used in the standalone deploy mode
# =====================================================================
export SPARK_MASTER_HOST=dstorm
export SPARK_MASTER_PORT=7077
export SPARK_MASTER_WEBUI_PORT=8080 # JupyterLab uses port 8888.
# ---------------------------------------------------------------------
export SPARK_WORKER_CORES=3     # 12  # To Set number of worker cores to use on this machine.
export SPARK_WORKER_MEMORY=4g         # Total RAM workers have to give executors (e.g. 2g)
export SPARK_WORKER_WEBUI_PORT=8081   # Default: 8081
export SPARK_WORKER_INSTANCES=4 # 5   # Number of workers on this server.
# ---------------------------------------------------------------------
export SPARK_DAEMON_MEMORY=1g      # To allocate to MASTER, WORKER and HISTORY daemons themselves (Def: 1g).
# =====================================================================

# =====================================================================
# Generic options for the daemons used in the standalone deploy mode
# =====================================================================
export SPARK_PID_DIR=${SPARK_HOME}/pid # PID file location.
# =====================================================================

在此配置下启动Spark MASTER WORKERS 之后,我仅用两个指向该Spark Standalone的Notebook选项卡启动 Jupyter 集群。

我的问题是,一个笔记本标签的单元格数量(大约是第5或第6单元格)会消耗掉所有Cores。让第二个标签页处于饥饿状态,因为它等待(但从未获得)资源,因此停止了第二个标签页中的所有进度。我可以在SparkUI中确认这一点:第一个“笔记本”选项卡的 RUNNING 状态为所有核心;以及第二个标签为 0核 WAITING 状态。尽管第一台笔记本电脑已经完成了它的运行(即到达底部并完成了最后一个单元格),但仍然如此。

顺便说一句,这种等待不仅限于Jupyter。如果我接下来在CLI上启动Python / PySpark并连接到同一集群,它也必须等待。

在所有三种情况下,我都会得到一个session,如下所示:

spark_sesn = SparkSession.builder.config(conf = spark_conf).getOrCreate()

请注意,这些笔记本选项卡或CLI上没有任何繁重的工作。相反,它非常轻巧(仅用于测试)。

我配置有误,还是我的基本发行概念不正确?我认为这里应该多路复用,而不是阻塞。也许这是一个会话共享问题? (即.getOrCreate())。

我尝试过使用CORES + WORKER-INSTANCES(例如12 x 5)的组合,但是出现了同样的问题。

嗯。好吧,我会继续调查(该睡觉了)。 =:)

预先感谢您的投入和见解。

1 个答案:

答案 0 :(得分:1)

您是否开始了随机播放服务?如果没有,则需要这样:

$SPARK_HOME_DIR/sbin/start-shuffle-service.sh

然后,您需要启用dynamicAllocation并向sparkSession指定启用随机播放服务。

为此,请在您的SparkConf()中声明它:

spark.dynamicAllocation.enabled = true
spark.shuffle.service.enabled = true

查看: https://spark.apache.org/docs/latest/configuration.html#dynamic-allocation

一旦您等待“ spark.dynamicAllocation.executorIdleTimeout”时间,执行程序将被删除。您可以在Standalone Master UI和Spark app UI上看到它。

另一个好的链接:https://dzone.com/articles/spark-dynamic-allocation