本文翻译自:Managing Relations Inside Elasticsearch | Elastic
是否曾经有过疑问:--num-executors
, --executor-memory
and --execuor-cores
这些参数该如何配置?
- 让我们看一些建议以便能够更好的理解
- 亲自动手,用一些示例集群来推到合适的参数
理论先行
以下是一些配置时的建议内容:
- Hadoop/Yarn/OS 守护进程:当我们在 Yarn 一类的集群管理器中运行 Spark 应用时,后台会伴随着守护进程的运行,比如:NameNode,Secondary NameNode,DataNode,JobTracker,以及 TaskTracker。因而,当指定
num-executors
时,我们需要保证留有足够的 CPU 核树(每个节点 1 核)以确保这些守护进程能够顺利运行。 - Yarn ApplicationMaster (AM):ApplicationMaster 会从 ResourceManager 那里申请资源,并通过 NodeManager 执行并监控 Container 及其中的资源消耗。如果在 Yarn 中启动应用,我们需要为 AM 流出所需的资源( 大约 1024MB 的内存以及 1 个 Executor )
- HDFS 吞吐:HDFS 客户端应对大量的并发线程性能不佳。据观察,当达到每个执行单元 5 个任务时,HDFS 会达到上限的吞吐量。因而,最好保证每个 Executor 的核数低于这个值。
- 内存开销:下图描述了 Spark on Yarn 的内存占用情况:
从上图中,我们需要注意两件事:
- 每个 Executor 所申请的内存 =
spark-executor-memory
+spark.yarn.executor.memoryOverhead
-
spark.yarn.executor.memoryOverhead
= Max( 384MB, 7% *spark.executor-memory
)
也就是说,如果我们为每个 Executor 申请 20GB内存,AM 实际上将会申请 20GB + memoryOverhead = 20 + 20 * 7% ~= 23GB。
- Executor 中含有过多内存通常会导致过度的 GC 延迟;
- Thiy Executor( 仅含有单核,以及仅仅足够单个 task 运行所需的内存 )会失去在单个 JVM 中运行多个任务的优势。
动手实践
现在,假设我们有 10 个服务器节点,他们的配置如下:
**服务器配置**
节点数:10
单个节点核数:16
单个节点内存:64GB
让我们考虑一下不同的参数配置:
方法一:Tiny Executor( 每个 Executor 单核 )
Tiny Executor 意味着每个 Executor 仅有一个核。下表在这一情况下的参数配置:
- --num-executors = 节点总核数
= 单个节点核数 * 集群的节点个数
= 16 x 10 = 160
- --executor-cores = 1 ( 每个 executor 单核 )
- --executor-memory = 每个 Executor 的内存数
= 每个节点的内存数 / 每个节点的 Executor 数
= 64GB / 16 = 4GB
分析: 如上述,当每个 Executor 仅有一个核时,我们无法利用同一 JVM 运行多个 task 的优势。同样的,利用 broadcast
和 accumulator
进行变量共享/缓存时,需要在每个节点的每个核中进行复制操作。此外,我们也没有为 Hadoop/Yarn 守护进程留有足够的内存资源。这种方法不好。
方法二:Fat Executor( 每个节点一个 Executor )
Fat Executor 意味着每个节点一个 Executor,下表展示了相应的 Spark 配置:
- --num-executors = 集群节点数
= 10
- --executor-cores = 单节点核数
= 16
- --executor-memory = 单节点内存数 / 每个节点的 Executor 数
= 64GB / 1 = 64GB
分析: 当每个 Executor 分配 16 核时,除了 AM 和守护进程没有考虑在内以外,HDFS 的吞吐将会受制,且将会导致国度的 GC。因为,这种方法不好。
方法三:Fat 和 Tiny 之间的平衡方案
根据我们之前的建议:
- 基于上述建议,让我们为每个 Executor 分配 5 核 =>
--executor-cores
= 5 ( 为了更好地 HDFS 吞吐 ) - 在每个节点中,为 Hadoop/Yarn 守护进程留出 1 核 => 单节点的可用核数 = 16 - 1 = 15
- 因而,总可用核数 = 15 * 10 = 150
- 可用的 executor 数 = ( 总核数 / 每个 executor 的核数 )= 150 / 5 30
- 留出一个 Executor 用于 ApplicationMaster =>
--num-executors
= 29 - 每个节点的 Executor 数 = 30 / 10 = 3
- 每个节点的内存数 = 64GB / 3 ~= 21 GB
- 计算额外开销 = 7% * 21 GB = 3 GB。因而,实际的
--executor-memory
= 21 - 3 = 18 GB
因而,推荐的配置为:29 个 Executor,每个 Executor:18 GB 内存及 5 核。
分析:不难看出方法三是如何在 Fat 和 Tiny 之间保持平衡的。其保证了 Fat Executor 的并行度及 Tiny Executor 的吞吐量。
结论
如下:
在对 Spark 应用的配置时记住如下建议:
- 为 Yarn AM 预留所需的资源;
- 为 Hadoop/Yarn/OS 守护进程预留资源;
- 了解 Spark 内存利用模型
此外,分析三种参数配置方法:
- Tiny Executors - 单核 Executor
- Fat Executor - 每个节点对应一个 Executor
- 推荐的做法 - 按上述建议在 Fat 和 Tiny 之间保持平衡
--num-executors
,--executor-cores
and --executor-memory
这三个参数控制了 Spark 应用所能使用的 CPU 数量及内存数,在 Spark 性能上起到至关重要的作用。让用户理解配置的正确方法是至关重要的。希望这篇博客能够帮助你了解这些。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。