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

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

我的环境是:

具有3个节点的Spark Cluster(每个节点32个内核和32GB内存).每个节点运行1个Worker.

spark.max.cores = 96

集群管理器= Standalone

部署模式= client

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

设置每个执行程序的核心数有什么影响？

每个执行程序的内核确实对运行时有重大影响,但仅适用于较小的分区大小而不适用于大分区,为什么？

它是否会以任何方式影响并行性(我不确定是这样)？

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

垃圾收集; 现在,同一进程空间中的任务在内存分配/垃圾收集期间更多地相互影响,成为共享的争用瓶颈.

像HDFS客户端这样的共享客户端在使用大量线程时可能会出现争用问题.

像akka线程这样的共享池可能会在进程中过多地使用过多的并发任务.

任何需要同步的共享数据结构意味着在线程上下文切换和等待锁上花费更多的壁挂时间; 这包括指标报告等内容

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

减少每个执行程序的内存开销; 如果每个任务需要一定量的内存,理论上你可以将更多并发任务打包到一台具有单个非常大的执行程序的机器上,而不是许多小执行程序.

共享内存空间对于广播变量/数据等内容来说是一个很大的好处.

Cloudera博客文章解释了很多这些权衡和具体数字,特别是关于过大执行程序的缺点.

在少量分区的情况下,理论上具有比执行器更少的分区,只要任务在每种情况下均匀地分布到不同的执行器中,性能应该与更大的执行器更好或相等.但是,如果任务的打包将它们全部放在一个执行程序上,那么它只取决于工作量; 重量级的东西可以受益于这样一个事实:一切都是本地的,但HDFS I/O重的东西会受到争用.