我试图了解在 YARN 上运行 Spark 作业时核心数量和执行器数量的关系。
测试环境如下：
该作业使用以下配置运行：
--master yarn-client --executor-memory 19G --executor-cores 7 --num-executors 3（每个数据节点的执行器，使用与核心一样多的数量）
--master yarn-client --executor-memory 19G --executor-cores 4 --num-executors 3（减少的核心数量）
--master yarn-client --executor-memory 4G --executor-cores 2 --num-executors 12（更少的核心，更多的执行者）
经过时间：
50分15秒
55分48秒
31分23秒
令我惊讶的是，（3）要快得多。
我认为（1）会更快，因为洗牌时执行器之间的通信会更少。
尽管 (1) 的核心数少于 (3)，但核心数并不是关键因素，因为 2) 确实表现良好。
（以下内容是在 pwilmot 回答后添加的。）
作为信息，性能监视器屏幕截图如下：
- Ganglia 数据节点摘要 (1) - 作业于 04:37 开始。
- Ganglia 数据节点摘要 (3) - 作业于 19:47 开始。请忽略该时间之前的图表。
该图大致分为 2 个部分：
- 第一：从start到reduceByKey：CPU密集型，无网络活动
- 第二：reduceByKey之后：CPU降低，网络I/O完成。
如图所示，(1) 可以使用给定的 CPU 能力。所以，这可能不是线程数量的问题。
如何解释这个结果呢？
为了让这一切变得更加具体，这里有一个配置 Spark 应用程序以使用尽可能多的集群的工作示例
可能：想象一个集群六个节点运行 NodeManagers，每个
配备有16 核和 64GB 内存。 NodeManager 的容量，
yarn.nodemanager.resource.memory-mb 和
yarn.nodemanager.resource.cpu-vcores，可能应该设置为 63 *
1024 = 64512（兆字节）和 15。我们避免分配 100%
的资源到 YARN 容器，因为节点需要一些
运行操作系统和 Hadoop 守护进程的资源。在这种情况下，我们留下一个
千兆字节和这些系统进程的核心。 Cloudera Manager 提供帮助
通过考虑这些并配置这些 YARN 属性
自动地。
第一个冲动可能是使用--执行器数量 6
--执行器核心 15 --执行器内存 63G。然而，这是错误的方法，因为：
63GB + 执行器内存开销不适合 63GB 容量
NodeManager 的。应用主控会占用一个核心
节点数，这意味着将没有空间容纳 15 核执行器
在该节点上。每个执行器 15 个核心可能会导致 HDFS I/O 不良
吞吐量。
更好的选择是使用--执行者数量 17
--执行器核心 5 --执行器内存 19G. Why?
此配置会导致除第一个执行程序外的所有节点上都有三个执行程序
AM 将有两名执行者。
--executor-memory 的计算公式为（每个节点 63/3 个执行程序）= 21. 21 * 0.07 = 1.47。 21 – 1.47 ~ 19。
Cloudera 博客的一篇文章中给出了解释，操作方法：调整您的 Apache Spark 作业（第 2 部分） https://blog.cloudera.com/how-to-tune-your-apache-spark-jobs-part-2/.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
