例如，我目前有一个由一个主服务器和4个工作器组成的DataProc集群，每台计算机具有8个vCPU和30GB内存。
每当我向集群提交作业时，集群最多总共提交11GB的内存，并且仅委派2个工作节点来执行工作，并且在那些节点上仅使用2个vCPU资源。这样一来，只需几分钟即可完成的工作大约需要一个小时才能完成。
我尝试在主节点上编辑spark-defaults.conf文件，并尝试运行带有参数spark-submit的{{1}}命令，但都没有任何效果。
这些集群只会被旋转以执行单个任务，然后被拆除，因此不需要为其他任何作业保留资源。
答案 0 :(得分：4)
我设法通过将调度程序更改为FIFO而不是FAIR来解决问题，方法是在create命令末尾使用以下内容：
--properties spark:spark.scheduler.mode=FIFO
答案 1 :(得分：3)
您可能想查看您正在查看的内容是否与Dataproc set number of vcores per executor container有关-已知YARN报告的正在使用的vcore数量不正确，但这只是表面上的缺陷。在具有8核机器的Dataproc集群上，默认配置已经为每个执行程序设置了4个核心；如果将YARN单击到Spark appmaster，则应该看到Spark确实能够为每个执行者打包4个并发任务。
该部分说明了每个节点“仅使用2个vCPU”的样子。
该作业仅涉及两个工作节点的事实表明，尽管还有很多工作要做；您获得的并行度与how well the data is partitioned有关。如果您有无法拆分的输入文件（例如gzip文件），那么很遗憾，没有简单的方法来增加输入并行度。但是，至少在以后的管道阶段中，或者如果您确实有可拆分的文件，则可以通过在读取时指定Spark分区的数量或在代码中调用repartition来提高并行度。根据您输入的大小，您还可以尝试减少fs.gs.block.size；默认为134217728（128MB），但您可以在创建集群时将其设置为该值的一半或四分之一或其他值：
--properties core:fs.gs.block.size=67108864
或在工作提交时：
--properties spark.hadoop.fs.gs.block.size=67108864