3
本文翻译自:Managing Relations Inside Elasticsearch | Elastic

是否曾经有过疑问:--num-executors, --executor-memory and --execuor-cores 这些参数该如何配置?

  1. 让我们看一些建议以便能够更好的理解
  2. 亲自动手,用一些示例集群来推到合适的参数

理论先行

以下是一些配置时的建议内容:

  • 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 的内存占用情况:

从上图中,我们需要注意两件事:

  1. 每个 Executor 所申请的内存 = spark-executor-memory + spark.yarn.executor.memoryOverhead
  2. 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 的优势。同样的,利用 broadcastaccumulator 进行变量共享/缓存时,需要在每个节点的每个核中进行复制操作。此外,我们也没有为 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 内存利用模型

此外,分析三种参数配置方法:

  1. Tiny Executors - 单核 Executor
  2. Fat Executor - 每个节点对应一个 Executor
  3. 推荐的做法 - 按上述建议在 Fat 和 Tiny 之间保持平衡

--num-executors--executor-cores and --executor-memory 这三个参数控制了 Spark 应用所能使用的 CPU 数量及内存数,在 Spark 性能上起到至关重要的作用。让用户理解配置的正确方法是至关重要的。希望这篇博客能够帮助你了解这些。


dailybird
1.1k 声望73 粉丝

I wanna.