記事のディレクトリ
パラメータ説明
executor-memory各エグゼキュータに割り当てられたメモリを表し、デフォルトは1Gです。
executor-coresこれは、各コア監査キュータすなわちに割り当てられた番号を表し、デフォルトのモードは、ヤーン上の火花です。
num-executors現在のアプリケーションの起動エグゼキュータの数として表現。あなたは（動的割り当てを有効にした場合spark.dynamicAllocation.enabled、デフォルトの数のエグゼキュータはfalse）、初期起動があるnum-executors設定の数。
心に留めておくべき以下の4つの提案
Hadoop/Yarn/OS Deamons：私たちはときにcluster manager、このような糸スパーククラスタなどのタスクを実行するとき、実行するためにいくつかのバックグラウンドプロセスが存在することになるNameNode、Secondary NameNode、DataNode、ResourceManager、NodeManagerように。したがって、三つのパラメータの上決定する前に、我々はそれらのコアデーモンのための十分なままにすることを確認する必要があります（一般每个节点留一个core）。Yarn ApplicationMaster (AM)：ApplicationMaster担当ResourceManagerのアプリケーションやリソースとNodeManagers実装と一緒に監視containersし、そのリソース消費を。我々は、糸モードに火花なら、私たちはする必要がありますApplicationMaster（脇いくつかのリソースを設定します1G和1个Executor）。HDFS Throughput：HDFSクライアントは、マルチスレッド同時実行の問題になります。研究は、HDFSは同時に最高であるスループット各エグゼキュータの書き込みは、5つのタスクを実行しながら、ことが示されています。したがって、それは推奨されるexecutor-cores値の遺跡を5以下で。MemoryOverhead：私たちは、糸と配備モード=クラスタ例にスパーク。バージョン2.3の前に、
によってspark.yarn.executor.memoryOverheadmemoryOverheadにエグゼキュータの定義。10％公式比は、通常、6％と10％との間で、それらのほとんどは7％に選びました。特定基準1. 6.3スパーク特性
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)
バージョン2.3では、それがされてspark.executor.memoryOverhead定義されました。memoryOverheadための前記VM overheads, interned strings, other native overheadsのような。
GCは通常、割り当てられたエグゼキュータの実装に大きな遅延が大きなメモリを持っている原因となります。
エグゼキュータは、（例えば、非常に小さい行う一个coreようJVM（で、必要なタスクを実行するために、十分なメモリ）每个Executor就是一个独立的JVM实例）失われ、同時に複数のタスクの利点を実行することができます。
設定パラメータ
次のように最初には、クラスタ構成を前提とし
10 Nodes
16 cores per Node
64GB RAM per Node
方法A：小型エグゼキュータ（コアごとに1つの執行）
--num-executors = 16 x 10 = 160
--executor-cores = 1 (one executor per core)
--executor-memory = `mem-per-node/num-executors-per-node`
= 64GB/16 = 4GB
この中でOne Executor per core設定する場合、我々はJVMの内部で同時に実行される複数のタスクを利用することはできません。一方、共有変数可変ブロードキャスト（放送変数）とアキュムレータ（アキュムレータ）は、各コアA上のすべてのノードに複製される（各ノードに16回コピーされます因为共享变量会复制到每个executor上）。そして、我々はApplicationManagerのをカウントアップするために、バックグラウンドなど名前ノードなどのプロセス、またリソースに脇に十分なリソースを設定しないでください。非常に悪いです！！！
方法2：脂肪エグゼキュータ（ノードごとに1つのエグゼキュータ）
--num-executors = 10
--executor-cores = 16
--executor-memory = `mem-per-node/num-executors-per-node`
= 64GB/1 = 64GB
それぞれのすべてのコアを得るために執行上のノードを除いてApplicationManagerはさておき、バックグラウンド・プロセスは、HDFSのスループットが影響を受け、GCの検証を伴うだろう。また、非常に悪いです！！！
方法3：脂肪のバランス（対）タイニー
まず、パラメータに応じて上記の推奨、我々は、5つのコアエグゼキュータのそれぞれに割り当てるexecutor-cores=5HDFSのスループットは、より友好的になりますので、。
バックグラウンドプロセスとしての第2は、コア、各ノードが利用可能なコアの数が残ります16 - 1 = 15。だから、可能なコアクラスタの総数です15 x 10 = 150。
第三に、各ノード上の執行数は、15 / 5 = 3執行の合計数のクラスタが利用可能です3 * 10 = 30。するにはApplicationManager、その後、エグゼキュータを残しますnum-executors=29。
第四に、各ノードは、各メモリに割り当てることができる執行ある(64GB-1GB) / 3 = 21GB（サブトラクトデーモンが1ギガバイトと残され）、除去MemoryOverHead=max(384MB, 7% * 21GB)=2GBので、executor-memory=21GB - 2GB = 19GB。
だから、最後のパラメータの設定があります
--num-executors = 29
--executor-cores = 5
--executor-memory = 19GB
このアプローチは、利点がJVMインスタンス内のタスクを同時に実行することができるだけでなく、HDFSのスループットを確実にするために保証するだけでなく。
方法4：法に基づく3は、各エグゼキュータので、多くのメモリを必要としません。
方法3は、各エグゼキュータに割り当てられたメモリは、19ギガバイト、10ギガバイトのメモリが十分であると仮定されます。したがって、この時点で私たちができるexecutor-cores3に減らして減らし、各ノードが持つことができる15 / 3 = 5エグゼキュータが、その後、エグゼキュータの総数が利用可能である(5 * 10) - 1 =49各ノードは、各エグゼキュータのメモリに割り当てることができている上、(64GB-1GB) / 5 = 12GB削除
MemoryOverHead=max(384MB, 7% * 12GB)=1GBして、executor-memory=12GB - 1GB = 11GB
それが最後であります設定パラメータは、
--num-executors = 49
--executor-cores = 3
--executor-memory = 11GB
参考サイト
distribution_of_executors_cores_and_memory_for_spark_application
方法ツーチューン火花エグゼキュータ-数コア・アンド・エグゼキュータメモリ
リソース割り当て構成-スパーク糸
