例如，我目前有一个DataProc集群，由一个主服务器和4个工作器组成，每台机器有8个vCPU和30GB内存。
每当我向集群提交作业时，集群总共最多承诺11GB，并且仅使用2个工作节点来完成工作，并且在这些节点上仅使用2个vCPU资源。这使得一项只需几分钟的工作需要花费近一个小时才能完成。
我已经尝试在主节点上编辑spark-defaults.conf文件，并尝试使用参数spark-submit运行我的--executor-cores 4 --executor-memory 20g --num-executors 4命令，但都没有任何效果。
这些集群只会被分离以执行单个任务，然后将被拆除，因此不需要为任何其他作业保留资源。
我设法通过将调度程序更改为FIFO而不是FAIR来解决我的问题，使用下面的create命令结束：
--properties spark:spark.scheduler.mode=FIFO
你可能想知道你所看到的是否与Dataproc set number of vcores per executor container有关 - 已知YARN报告的使用中的vcores数量是不正确的，但它只是一个美容缺陷。在具有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