8

私が実行しているいくつかの Spark LDA トピック モデリング (主に一見ランダムな間隔での関連付け解除エラー) でさまざまな問題が発生しています。これは、問題のある自動クラスター構成に関連しているようです。私の最新の試みでは、マスター ノードとワーカー ノードの両方に n1-standard-8 マシン (8 コア、30 GB RAM) を使用します (6 ワーカー、合計 48 コア)。

しかし、私が見ると、/etc/spark/conf/spark-defaults.confこれがわかります：

spark.master yarn-client
spark.eventLog.enabled true
spark.eventLog.dir hdfs://cluster-3-m/user/spark/eventlog

# Dynamic allocation on YARN
spark.dynamicAllocation.enabled true
spark.dynamicAllocation.minExecutors 1
spark.dynamicAllocation.initialExecutors 100000
spark.dynamicAllocation.maxExecutors 100000
spark.shuffle.service.enabled true
spark.scheduler.minRegisteredResourcesRatio 0.0

spark.yarn.historyServer.address cluster-3-m:18080
spark.history.fs.logDirectory hdfs://cluster-3-m/user/spark/eventlog

spark.executor.cores 4
spark.executor.memory 9310m
spark.yarn.executor.memoryOverhead 930

# Overkill
spark.yarn.am.memory 9310m
spark.yarn.am.memoryOverhead 930

spark.driver.memory 7556m
spark.driver.maxResultSize 3778m
spark.akka.frameSize 512

# Add ALPN for Bigtable
spark.driver.extraJavaOptions -Xbootclasspath/p:/usr/local/share/google/alpn/alpn-boot-8.1.3.v20150130.jar
spark.executor.extraJavaOptions -Xbootclasspath/p:/usr/local/share/google/alpn/alpn-boot-8.1.3.v20150130.jar

しかし、これらの値はあまり意味がありません。なぜ 4/8 executor コアのみを使用するのですか? 9.3 / 30GB RAM しかありませんか? 私の印象では、この構成はすべて自動的に処理されるはずでしたが、手動で調整しようとしてもうまくいきません。

たとえば、次のコマンドでシェルを起動しようとしました。

spark-shell --conf spark.executor.cores=8 --conf spark.executor.memory=24g

しかし、これは失敗しました

java.lang.IllegalArgumentException: Required executor memory (24576+930 MB) is above the max threshold (22528 MB) of this cluster! Please increase the value of 'yarn.scheduler.maximum-allocation-mb'.

で関連する値を変更しようとしましたが/etc/hadoop/conf/yarn-site.xml、効果がありませんでした。別のクラスター セットアップを試しても (たとえば、60 GB 以上の RAM を持つエグゼキューターを使用)、同じ問題が発生します。何らかの理由で、最大しきい値が 22528MB のままです。

ここで間違っていることがありますか、それとも Google の自動構成の問題ですか?

4

1 に答える 1

9

マスター マシン タイプがワーカー マシン タイプと異なるクラスターのデフォルトのメモリ構成には、いくつかの既知の問題がありますが、あなたの場合はそれが主な問題ではないようです。

次を見たとき。

spark.executor.cores 4
spark.executor.memory 9310m

これは実際には、各ワーカー ノードが 2 つのエグゼキューターを実行し、各エグゼキューターが 4 つのコアを使用して、各ワーカーで 8 つのコアすべてが実際に使い果たされることを意味します。このように、AppMaster に 1 台のマシンの半分を与えると、AppMaster はエグゼキューターの隣にうまく詰め込むことができます。

NodeManagers に与えられるメモリの量は、NodeManager デーモン自体とその他のオーバーヘッドを残す必要があります。DataNode などの他のデーモン サービスであるため、最大 80% が NodeManagers に残されます。さらに、割り当ては最小 YARN 割り当ての倍数でなければならないため、最も近い割り当て倍数にフロアリングした後、n1-standard-8 の 22528MB はそこから得られます。

60 GB 以上の RAM を持つワーカーを追加すると、同じメモリ サイズのマスター ノードを使用している限り、最大しきい値の数値が高くなるはずです。

いずれにせよ、OOM の問題が発生している場合、最も重要なのは実行プログラムごとのメモリではなく、タスクごとのメモリです。spark.executor.coresまた、同時に増加している場合spark.executor.memory、タスクごとのメモリは実際には増加していないため、その場合、アプリケーション ロジックにより多くの余裕を与えることはありません。Spark はspark.executor.cores、同じメモリ空間で実行する同時実行タスクの数を決定するために使用します。

taskごとにより多くのメモリを実際に取得するには、主に次のことを試してください。

  1. n1-highmem-* マシンタイプを使用する
  2. spark.executor.memory を同じままにして、spark.executor.cores を減らしてみてください。
  3. spark.executor.cores を同じままにして、spark.executor.memory を増やしてみてください。

上記の (2) または (3) を実行すると、すべてのコアを占有しようとするデフォルトの構成と比較して、実際にコアをアイドル状態のままにすることになりますが、highmemインスタンスに移動する以外に、タスクごとにより多くのメモリを取得する唯一の方法です。 .

于 2015-12-07T19:34:54.017 に答える