Spark：每个执行程序的核心对应用程序运行时没有影响

Question

我正在测试每个执行程序（--executor-cores）的不同核心数对Spark上SVD的运行时间的影响。在--executor-cores固定的情况下，主数据RDD的分区数量是变化的。但是，对于给定数量的RDD分区，不同--executor-cores的SVD计算时间似乎没有显着变化。这有点令人困惑。

我的环境是：

• 具有3个节点的Spark Cluster（每个节点32个内核和32GB内存）。每个节点运行1个Worker。
• spark.max.cores = 96
• 群集管理器= Standalone
• 部署模式= client

我已经为--executor-cores = [4, 16]绘制了结果，并且可以看出，对于给定的分区大小，分区大小增加时的计算时间之间没有太大差异。所以我的问题是：

• 设置每个执行程序的核心数有什么影响？
• 每个执行程序的内核确实对运行时有重大影响，但仅针对较小的分区大小而不是大分区，为什么？
• 它是否会以任何方式影响并行性（我不确定）？

Answer 1

通常，每个执行程序的最佳核心平衡因工作负载而异;虽然每个执行程序的核心数通常会减少每个执行程序的开销，但还有一些其他因素会影响性能反向每个执行程序的核心数量，主要是围绕流程全局共享资源和争用瓶颈：< / p>

1. 垃圾收集;现在，同一进程空间中的任务在内存分配/垃圾收集期间会更多地相互影响，成为共享的争用瓶颈。
2. 使用大量线程时，HDFS客户端等共享客户端可能会出现争用问题。
3. 像akka线程这样的共享池可能会在进程中过多订阅并发任务。
4. 任何需要同步的共享数据结构意味着在线程上下文切换和等待锁上花费更多的壁挂时间;这包括metrics reporting
之类的内容

另一方面，为每个执行程序添加更多内核的好处包括：

1. 减少每个执行程序的内存开销;如果每个任务需要一定量的内存，理论上你可以将更多的并发任务打包到一台具有单个非常大的执行程序的机器上，而不是许多小执行程序。
2. 共享内存空间对broadcast variables/data等内容有很大好处。

this Cloudera blog post解释了很多这些权衡和具体数字，特别是关于过大执行者的缺点。

对于少量分区，理论上分区数少于执行程序，只要任务分散到不同的执行程序中，性能应该与更大的执行程序更好或相等在每种情况下都很好。但是，如果任务的打包将它们全部放在一个执行程序上，那么它只取决于工作量;重复播放的东西可以从这样一个事实中受益，即所有进程都是本地的，但HDFS I / O重的东西会受到争用。