我正在测试每个执行器的不同核心数量 (--executor-cores) 对 Spark 上 SVD 运行时的影响。当--executor-cores固定后，主数据RDD的分区数量会发生变化。然而，对于给定数量的 RDD 分区，不同 --executor-cores 的 SVD 计算时间似乎没有显着变化。这有点令人困惑。
我的环境是:
- 具有 3 个节点的 Spark 集群(每个节点 32 个核心和 32GB 内存)。每个节点运行 1 个 Worker。
- spark.max.cores = 96
- 集群管理器=
独立 - 部署模式 =
客户端
我已经绘制了 --executor-cores = [4, 16] 的结果，正如人们所看到的，对于给定的分区大小，分区时的计算时间之间没有太大差异尺寸增加。所以我的问题是:
- 设置每个执行器的核心数有什么影响？
- 每个执行器的核心数确实对运行时有显着影响，但仅适用于小分区，而不适用于大分区，为什么？
- 它是否会以任何方式影响并行性(我不确定是否会影响)？
最佳答案
一般来说，每个执行器的核心最佳平衡因工作负载而异；虽然每个执行器拥有更多核心通常会减少每个执行器的开销，但还有一些其他考虑因素会与每个执行器的核心数量成反比地影响性能，主要围绕进程全局共享资源和争用瓶颈:
- 垃圾收集；现在，同一进程空间中的任务在内存分配/垃圾收集期间相互影响更大，成为共享争用瓶颈。
- 使用大量线程时，HDFS 客户端等共享客户端可能会出现争用问题。
- 像 akka 线程这样的共享池可能会因进程中的并发任务过多而被超额订阅。
- 任何需要同步的共享数据结构都意味着在线程上下文切换和等待锁上花费更多的时间；这包括类似 metrics reporting 的内容
另一方面，为每个执行器添加更多核心的好处包括:
- 减少每个执行器的内存开销；如果每个任务需要一定量的内存，理论上，与许多小型执行器相比，您可以将更多并发任务打包到具有单个非常大的执行器的机器上。
- 共享内存空间对于 broadcast variables/data 这样的事情来说是一个很大的好处。 .
许多这些权衡和具体数字，特别是关于过大执行器的缺点，在 this Cloudera blog post 中进行了解释。 .
在分区数量较少的情况下，理论上，分区数少于执行器数时，只要任务均匀分布到不同的执行器中，性能应该优于或等于较大的执行器每种情况都很好。然而，如果任务打包将它们全部放在一个执行器上，那么它只取决于工作负载；重洗牌的东西可以受益于这样一个事实:一切都是本地进程，但 HDFS I/O 重的东西会受到争用。
关于apache-spark - Spark : No effect of cores per executors on application runtime，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34073857/