标签：master 重要 守护 for 堆内存 track follow 现在 多少
网上看到的关于Executor，Cores和Memory的分配相关博客，先记录下来，再汇总。
<1>第一篇 Spark处理多少数据是否需要多少内存
Spark处理1Tb数据不需要1Tb的内存。
在跑Spark-On-Yarn程序的时候，往往会对几个参数（num-executors，executor-cores，executor-memory等）理解很模糊，从而凭感觉地去指定值，这是不符合有追求程序员信仰的。因此，搞懂它们，很有必要。
本文翻译自https://spoddutur.github.io/spark-notes/distribution_of_executors_cores_and_memory_for_spark_application.html。
是否曾经想要知道如何根据你的集群，配置这些Spark运行参数：--num-executors, --executor-memory and --execuor-cores 呢？
Full memory requested to yarn per executor = spark-executor-memory + spark.yarn.executor.memoryOverhead spark.yarn.executor.memoryOverhead = Max(384MB, 7% of spark.executor-memory)
所以，如果我们申请了每个executor的内存为20G时，对我们而言，AM将实际得到20G+ memoryOverhead = 20 + 7% * 20GB = ～23G内存。
现在，我们考虑一个10个节点的如下配置的集群，并分析不同参数设置的结果。
集群配置如下：
**集群配置:** 10个节点 每个节点16核 每个节点64G内存
Tiny executors表示一个executor配置一个core。下表描述了该方案下的参数配置。
- ‘--num-executors‘ = ‘该方案下，每个executor配置一个core‘
= ‘集群中的core的总数‘
= ‘每个节点的core数目 * 集群中的节点数‘
= 16 x 10 = 160
- ‘--executor-cores‘ = 1 (每个executor一个core)
- ‘--executor-memory‘ = ‘每个executor的内存‘
= ‘每个节点的内存/每个节点的executor数目‘
= 64GB/16 = 4GB
分析：当一个executor只有一个core时，正如我们上面分析的，我们可能不能发挥在单个JVM上运行多任务的优势。此外，共享/缓存变量（如广播变量和累加器）将复制到节点的每个core，这里是16次。并且，我们没有为Hadoop / Yarn守护进程留下足够的内存开销，我们也没有计入ApplicationManager。因此，这不是一个好的方案！
Fat executors表示一个executor独占一个节点。下表描述了该方案下的参数配置：
- `--num-executors` = `该方案下，一个executor独占一个节点`
= `集群中的节点的数目`
= 10
- `--executor-cores` = `一个节点一个executor意味着每个executor独占节点中所
有的cores`
= `节点中的core的数目`
= 16
- `--executor-memory` = `每个executor的内存`
= `节点的内存/节点中executor的数目`
= 64GB/1 = 64GB
分析：每个executor独占16个核心，则ApplicationManager和守护程序进程则无法分配到core，并且，HDFS吞吐量会受到影响，导致过多的垃圾结果。 同样地，该方案不好！
each ！
分析：很明显，第三种方案在Fat vs Tiny 两种方案中找到了合适的平衡点。毋庸置疑，它实现了Fat executor的并行性和Tiny executor的最佳吞吐量！
我们看到：
--num-executors, --executor-cores and --executor-memory..这三个参数在spark性能中扮演很重要的角色，他们控制这你的spark程序获得的CPU和内存的资源。对于用户来说，很有必要理解如何去配置它们。希望这篇博客对你有帮助。
标签：master 重要 守护 for 堆内存 track follow 现在 多少
原文地址：https://www.cnblogs.com/liuluvaliant/p/spark.html
