如何调整火花执行器数量，核心和执行器内存？

Question

您从哪里开始调优上面提到的params。我们是从执行器内存开始，得到执行器的数目，还是从核心开始，得到执行器的数目。我跟踪了链接。然而得到了一个高水平的想法，但仍然不确定如何或从哪里开始并得出最终结论。

Answer 1

下面的答案涵盖了标题中提到的3个主要方面--执行器的数量、执行器内存和核心的数量。可能还有其他参数，如驱动程序内存和其他我没有解决这个答案，但希望在不久的将来添加。

情况1硬件-6个节点，每个节点16个核心，64 GB RAM

每个执行器都是一个JVM实例。所以我们可以在一个节点中有多个执行器

Number of cores = Concurrent tasks as executor can run 

So we might think, more concurrent tasks for each executor will give better performance. But research shows that
any application with more than 5 concurrent tasks, would lead to bad show. So stick this to 5.

This number came from the ability of executor and not from how many cores a system has. So the number 5 stays same
even if you have double(32) cores in the CPU.

Coming back to next step, with 5 as cores per executor, and 15 as total available cores in one Node(CPU) - we come to 
3 executors per node.

So with 6 nodes, and 3 executors per node - we get 18 executors. Out of 18 we need 1 executor (java process) for AM in YARN we get 17 executors

This 17 is the number we give to spark using --num-executors while running from spark-submit shell command

From above step, we have 3 executors  per node. And available RAM is 63 GB

So memory for each executor is 63/3 = 21GB. 

However small overhead memory is also needed to determine the full memory request to YARN for each executor.
Formula for that over head is max(384, .07 * spark.executor.memory)

Calculating that overhead - .07 * 21 (Here 21 is calculated as above 63/3)
                            = 1.47

Since 1.47 GB > 384 MB, the over head is 1.47.
Take the above from each 21 above => 21 - 1.47 ~ 19 GB

So executor memory - 19 GB

硬件：相同的6个节点，32个核心，64 GB

5同样适用于良好的并发性

每个节点的执行器数=32/5~6

每个节点的执行器的核心数为5#=3

在这个阶段，这将导致21，然后根据我们的第一次计算19。但是由于我们认为10个就可以了（假设开销很小），所以我们不能将每个节点的执行器数切换到6个（比如63/10）。在每个节点6个执行器和5个核心的情况下，当我们只有16个核心时，它可以减少到每个节点30个核心。因此，我们还需要改变每个执行器的核心数。

所以再计算一下，

注意：如果启用了动态分配，则执行器数量的上限。也就是说，如果需要的话，spark应用程序可以消耗掉所有的资源。因此，在有其他应用程序正在运行的集群中，它们也需要内核来运行任务，请确保在集群级别执行。我的意思是你可以根据用户的访问权限为纱线分配特定数量的芯。因此，您可以创建spark_user maybe，然后为该用户指定核心（最小/最大）。这些限制是为了在spark和其他运行在纱线上的应用程序之间共享。

enabled-当它被设置为true时-我们不需要提到执行器。原因如下：

我们在spark-submit中给出的静态params数是整个作业持续时间的。然而，如果动态分配进入画面，将会有不同的阶段，如

然后根据负载（任务挂起）请求多少。这最终将是我们在Spark上给出的数字--以静态方式提交。因此，一旦设置了初始的执行器编号，我们将转到min（spark.dynamicallocation.minexecutors）和max（spark.dynamicallocation.maxexecutors）编号。

何时要求或给予：

我们什么时候请求新的执行器（spark.dynamicallocation.SchedulerBacklogTimeout）--在这么长的时间内有挂起的任务。所以请求。每一轮请求的执行者数量与上一轮相比呈指数增长。例如，一个应用程序将在第一轮中添加1个执行人，然后在随后的几轮中添加2、4、8个执行人。在一个特定的点上，上面的max出现了

• http://site.clairvoyantsoft.com/reditablement-resource-allocation-configurations-spark-application/
• http://spark.apache.org/docs/latest/configuration.html#dynamic-allocation
• http://spark.apache.org/docs/latest/job-scheduling.html#resource-allocation-policy