web-dev-qa-db-ja.com

spark yarn、コンテナはゼロ以外の終了コード143で終了しました

HDP 2.5を使用し、spark-submitを糸クラスターモードとして実行しています。

データフレームのクロス結合を使用してデータを生成しようとしました。すなわち

val generatedData = df1.join(df2).join(df3).join(df4)
generatedData.saveAsTable(...)....

df1ストレージレベルはMEMORY_AND_DISK

df2、df3、df4ストレージレベルはMEMORY_ONLY

df1にははるかに多くのレコードがあります。つまり、500万個のdf2からdf4までのレコードは最大100個です。そうすることで、BroadcastNestedLoopJoinEXPLAIN PLANを使用すると、私のEXPLAIN PLAYのパフォーマンスが向上します。

何らかの理由で常に失敗します。どうすればデバッグできるのか、どこでメモリが爆発するのかわかりません。

エラーログ出力：

16/12/06 19:44:08 WARN YarnAllocator: Container marked as failed: container_e33_1480922439133_0845_02_000002 on Host: hdp4. Exit status: 143. Diagnostics: Container killed on request. Exit code is 143
Container exited with a non-zero exit code 143
Killed by external signal

16/12/06 19:44:08 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container marked as failed: container_e33_1480922439133_0845_02_000002 on Host: hdp4. Exit status: 143. Diagnostics: Container killed on request. Exit code is 143
Container exited with a non-zero exit code 143
Killed by external signal

16/12/06 19:44:08 ERROR YarnClusterScheduler: Lost executor 1 on hdp4: Container marked as failed: container_e33_1480922439133_0845_02_000002 on Host: hdp4. Exit status: 143. Diagnostics: Container killed on request. Exit code is 143
Container exited with a non-zero exit code 143
Killed by external signal

16/12/06 19:44:08 WARN TaskSetManager: Lost task 1.0 in stage 12.0 (TID 19, hdp4): ExecutorLostFailure (executor 1 exited caused by one of the running tasks) Reason: Container marked as failed: container_e33_1480922439133_0845_02_000002 on Host: hdp4. Exit status: 143. Diagnostics: Container killed on request. Exit code is 143
Container exited with a non-zero exit code 143
Killed by external signal

このエラーの前にWARNまたはERRORログが表示されませんでした。何が問題ですか？メモリ消費量はどこで調べる必要がありますか？ SparkUIの）Storageタブに何も表示されません。ログはHDP 2.5のyarnリソースマネージャーUIから取得されました

[〜＃〜] edit [〜＃〜]コンテナログを見ると、Java.lang.OutOfMemoryError: GC overhead limit exceeded

メモリを増やす方法は知っていますが、もうメモリがありません。このエラーが発生することなく、4つのデータフレームでデカルト/製品結合を行うにはどうすればよいですか。

apache-sparkhiveyarnhortonworks-data-platform
7
David H

私もこの問題に出会い、いくつかのブログを参照して解決しようとします。 1. spark add conf bellowを実行します。

--conf 'spark.driver.extraJavaOptions=-XX:+UseCompressedOops -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps' \
--conf 'spark.executor.extraJavaOptions=-XX:+UseCompressedOops -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC  ' \
  1. Jvm GCの場合、次のメッセージが表示されます。
Heap after GC invocations=157 (full 98):
 PSYoungGen      total 940544K, used 853456K [0x0000000781800000, 0x00000007c0000000, 0x00000007c0000000)
  eden space 860160K, 99% used [0x0000000781800000,0x00000007b5974118,0x00000007b6000000)
  from space 80384K, 0% used [0x00000007b6000000,0x00000007b6000000,0x00000007bae80000)
  to   space 77824K, 0% used [0x00000007bb400000,0x00000007bb400000,0x00000007c0000000)
 ParOldGen       total 2048000K, used 2047964K [0x0000000704800000, 0x0000000781800000, 0x0000000781800000)
  object space 2048000K, 99% used [0x0000000704800000,0x00000007817f7148,0x0000000781800000)
 Metaspace       used 43044K, capacity 43310K, committed 44288K, reserved 1087488K
  class space    used 6618K, capacity 6701K, committed 6912K, reserved 1048576K  
}

  1. PSYoungGenとParOldGenの両方が99％である場合、Java.lang.OutOfMemoryError：さらにオブジェクトが作成された場合はGCオーバーヘッド制限を超えます。

  2. より多くのメモリリソースが利用可能な場合、エグゼキュータまたはドライバにメモリを追加してみてください。

--executor-memory 10000m \
-ドライバーメモリ10000m \

  1. 私の場合：PSYoungGenのメモリはParOldGenよりも小さいため、多くの若いオブジェクトがParOldGenメモリ領域に入り、最終的にParOldGenは使用できません。したがって、Java.lang.OutOfMemoryError：Javaヒープスペースエラーが表示されます。

  2. Executorのconfの追加：

'spark.executor.extraJavaOptions = -XX：NewRatio = 1 -XX：+ UseCompressedOops -verbose：gc -XX：+ PrintGCDetails -XX：+ PrintGCTimeStamps'

-XX：NewRatio = rate rate = ParOldGen/PSYoungGen

次のようなGC戦略を試すことができます

-XX:+UseSerialGC :Serial Collector 
-XX:+UseParallelGC :Parallel Collector
-XX:+UseParallelOldGC :Parallel Old collector 
-XX:+UseConcMarkSweepGC :Concurrent Mark Sweep

Java同時GCおよび並列GC

  1. 手順4と手順6の両方を実行してもエラーが発生する場合は、コードの変更を検討する必要があります。たとえば、MLモデルの反復回数を減らします。
6
Matiji66

すべてのコンテナとamのログファイルは、

yarn logs -applicationId application_1480922439133_0845_02

AMログのみが必要な場合は、

yarn logs -am -applicationId application_1480922439133_0845_02

このジョブで実行されたコンテナを検索する場合は、

yarn logs -applicationId application_1480922439133_0845_02|grep container_e33_1480922439133_0845_02

単一のコンテナログのみが必要な場合は、

yarn logs -containerId container_e33_1480922439133_0845_02_000002

これらのコマンドが機能するには、ログの集計がtrueに設定されている必要があります。そうでない場合、個々のサーバーディレクトリからログを取得する必要があります。

更新スワッピングを試すこと以外にできることは何もありませんが、パフォーマンスがかなり低下します。

GCのオーバーヘッド制限とは、GCが連続してノンストップで実行されているが、多くのメモリを回復できないことを意味します。その唯一の理由は、コードの記述が不十分で、後方参照が多い（単純な結合を行っているため疑わしい）か、メモリ容量に達しているためです。

5
Abhishek Anand