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

Question

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

我的环境是：

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

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

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

Answer 1

一般来说，每个执行程序的最佳核心平衡因工作负载而异；虽然每个执行器的更多核心通常会降低每个执行器的开销，但还有一些其他考虑因素会反向影响每个执行器的核心数量，主要是围绕进程全局共享资源和争用瓶颈：

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

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

1. 减少每个执行程序的内存开销；如果每个任务需要一定数量的内存，理论上你可以将更多并发任务打包到一台机器上，与许多小型执行器相比，只有一个非常大的执行器。
2. 共享内存空间成为broadcast variables/data 之类的一大优势。

this Cloudera blog post 中解释了很多这些权衡和具体数字，尤其是关于过大 executor 的缺点。

在partition数量较少的情况下，理论上partition比executor少，性能应该优于或等于更大的executor，只要任务平均分配到不同的executor在每种情况下都很好。但是，如果打包任务将它们全部放在一个执行器上，那么它只取决于工作量； shuffle-heavy 的东西可能会受益于这样一个事实，即一切都是本地进程，但 HDFS I/O-heavy 的东西会受到争用的影响。