Amazon EMR 上の Spark の「リクエストに応じてコンテナが強制終了しました。終了コードは 137 です」エラーを解決する方法を教えてください。

簡単な説明

コンテナ (Spark エグゼキューター) のメモリーが不足すると、YARN が自動的にそれを強制終了します。これにより、「リクエストに応じてコンテナが強制終了されました。終了コードは 137 です」エラーが発生します。これらのエラーは、狭い変換や広い変換のいずれの場合も、さまざまなジョブステージで発生する可能性があります。YARN コンテナは、OS のメモリが不足しているときに OS oom_reaper によって強制終了されることもあります。この場合、「リクエストに応じてコンテナが強制終了されました。終了コードは 137 です」エラーが発生します。

解決策

次の 1 つまたは複数の方法で、「終了ステータス: 137」ステージ障害を解決してください。

ドライバまたはエグゼキュータのメモリ容量を増やす

spark.executor.memory パラメータまたは spark.driver.memory パラメータを調整して、コンテナのメモリ容量を増やします (どちらを使うかはエラーの原因になったコンテナによって変わります)。

実行中のクラスターでの操作:

マスターノードの spark-defaults.conf を変更します。例:

sudo vim /etc/spark/conf/spark-defaults.conf
spark.executor.memory 10g
spark.driver.memory 10g

1 つのジョブの場合:

spark-submit を実行するときは、--executor-memory オプションまたは --driver-memory オプションでメモリ容量を増やしてください。例:

spark-submit --executor-memory 10g --driver-memory 10g ...

Spark パーティションをさらに追加する

コンテナメモリ容量を増やすことができない場合 (例えば、ノードで maximizeResourceAllocation を使用している場合) は、Spark パーティションの数を増やしてください。これにより、1 つの Spark タスクで処理されるデータ量が減り、1 つのエグゼキューターによるメモリの全体的な使用量も減ります。次の Scala コードを使用して Spark パーティションをさらに追加します。

val numPartitions = 500
val newDF = df.repartition(numPartitions)

シャッフルパーティションの数を増やす

広範囲にわたる変換 (join や groupBy など) 中にエラーが発生した場合は、シャッフルパーティションをさらに追加してください。デフォルト値は 200 です。

実行中のクラスターでの操作:

マスターノードの spark-defaults.conf を変更します。例:

sudo vim /etc/spark/conf/spark-defaults.conf
spark.sql.shuffle.partitions 500

1 つのジョブの場合:

spark-submit を実行するときに --conf spark.sql.shuffle.partitions オプションを使用すると、シャッフルパーティションをさらに追加できます。例:

spark-submit --conf spark.sql.shuffle.partitions=500 ...

エグゼキューターコアの数を減らす

エグゼキューターコアの数を減らすと、エグゼキューターが同時に処理するタスクの最大数が減ります。これにより、コンテナによるメモリ使用量が減ります。

実行中のクラスターでの操作:

マスターノードの spark-defaults.conf を変更します。例:

sudo vim /etc/spark/conf/spark-defaults.conf
spark.executor.cores  1

1 つのジョブの場合:

--executor-cores オプションを使用すると、spark-submit の実行時にエグゼキューターコアの数を減らすことができます。例:

spark-submit --executor-cores 1 ...

インスタンスサイズを増やす

YARN コンテナは、OS のメモリが不足しているときに OS oom_reaper によって強制終了されることもあります。oom_reaper が原因でこのエラーが発生する場合は、RAM の容量が大きいサイズの大きいインスタンスを使用してください。yarn.nodemanager.resource.memory-mb の値を下げて、YARN コンテナが Amazon EC2 のすべての RAM を使い果たさないようにすることもできます。

エラーの原因が oom_reaper によるものかどうかは、Amazon EMR インスタンスのログで dmesg コマンドの出力を確認すると判明します。まず、強制終了された YARN コンテナが実行されていたコアまたはタスクノードを探し出します。この情報は、YARN リソースマネージャー UI またはログで探すことができます。次に、コンテナが強制終了される前と後の、このノードの Amazon EMR インスタンスの状態ログをチェックして、何がプロセスを強制終了したかを確認します。

次の例では、YARN container_165487060318_0001_01_000244 に対応する ID 36787 のプロセスが、カーネル (Linux の OOM キラー) によって強制終了されました。

# hows the kernel looking
dmesg | tail -n 25

[ 3910.032284] Out of memory: Kill process 36787 (java) score 96 or sacrifice child
[ 3910.043627] Killed process 36787 (java) total-vm:15864568kB, anon-rss:13876204kB, file-rss:0kB, shmem-rss:0kB
[ 3910.748373] oom_reaper: reaped process 36787 (java), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

関連情報

Amazon EMR の Spark で「Container killed by YARN for exceeding memory limits (メモリ制限を超えたために YARN によってコンテナが強制終了されました)」というエラーを解決するにはどうすればよいですか?

Amazon EMR の Spark ジョブにおけるステージ障害の問題を解決するには、どうすれば良いですか。