web-dev-qa-db-ja.com

終了コードと終了ステータスは、火花のようなものですか？

sparkを糸で実行すると、常に終了コードと終了ステータスが表示されます。

以下にいくつかを示します。

  • CoarseGrainedExecutorBackend: RECEIVED SIGNAL 15: SIGTERM

  • ...failed 2 times due to AM Container for application_1431523563856_0001_000002 exited with exitCode: 10...

  • ...Exit status: 143. Diagnostics: Container killed on request

  • ...Container exited with a non-zero exit code 52:...

  • ...Container killed on request. Exit code is 137...

これらのメッセージのどれも有用だとは思っていません。..これらのメッセージが実際に何が悪いのかを解釈する機会はありますか？エラーを説明するテーブルを検索しましたが、何もありません。

上記から解読できるのは終了コード52だけですが、それはソースコード ここ を見たためです。それはOOMだと言っています。

これらの終了コードと終了ステータスの残りの解釈をやめるべきですか？または、これらの数字が実際に何かを意味するという明らかな方法を見逃していますか？

誰かがexit code、exit status、および有用なSIGNAL。しかし、私はちょうど今ランダムに推測しており、sparkを使用する私の周りの他のすべての人もそうです。

そして、最後に、なぜ終了コードのいくつかがゼロ未満であり、それらをどのように解釈するのですか？

例えば。 Exit status: -100. Diagnostics: Container released on a *lost* node

hadoopapache-sparkpysparkspark-dataframeyarn
20
Sother

終了コードとステータスもシグナルもSpark特定ではありませんが、Unixライクなシステムでプロセスが動作する方法の一部です。

終了ステータスと終了コード

終了ステータスと終了コードは、同じものに対する異なる名前です。終了ステータスは、終了後のプロセスの結果を示す0〜255の数値です。通常、終了ステータス0は成功を示します。他のコードの意味はプログラムに依存するため、プログラムのドキュメントで説明する必要があります。ただし、いくつかの確立された標準コードがあります。包括的なリストについては、 この回答 を参照してください。

Sparkが使用する終了コード

Spark sources で、次の終了コードを見つけました。それらの説明は、コード内のログステートメントとコメント、および終了ステータスが表示されたコードの理解から取得されます。

Hive Thrift ServerのSpark SQL CLIドライバー

  • 3：stdoutおよびstderrストリームのセットアップ中にUnsupportedEncodingExceptionが発生した場合。

スパーク/糸

  • 10：キャッチされていない例外が発生した場合
  • 11：_spark.yarn.scheduler.reporterThread.maxFailures_ executorの失敗が複数発生した場合
  • 12：レポータースレッドが例外で失敗した場合
  • 13：ユーザーがsparkコンテキストを初期化する前にプログラムが終了した場合、またはsparkコンテキストがタイムアウト前に初期化しないでください。
  • 14：これは_EXIT_SECURITY_として宣言されていますが、使用されることはありません
  • 15：ユーザークラスが例外をスローした場合
  • 16：最終ステータスが報告される前にシャットダウンフックが呼び出された場合。ソースコード内のコメントは、ユーザーアプリケーションの予想される動作を説明しています。

    シャットダウンフックによって呼び出された場合、ApplicationMasterのデフォルト状態は失敗します。この動作は、1.xバージョンと比較して異なります。ユーザーアプリケーションがSystem.exit(N)を呼び出すことによって事前に終了した場合、ここでこのアプリケーションを_EXIT_EARLY_で失敗としてマークします。適切にシャットダウンするには、ユーザーはSystem.exit(0)を呼び出してアプリケーションを終了しないでください。

執行者

  • 50：デフォルトのキャッチされない例外ハンドラに到達しました
  • 51：デフォルトのキャッチされていない例外ハンドラが呼び出され、例外のロギング中に例外が発生しました
  • 52：デフォルトのキャッチされない例外ハンドラに到達し、キャッチされない例外はOutOfMemoryErrorでした
  • 53：DiskStoreは何度も試行した後、ローカル一時ディレクトリの作成に失敗しました（spark.local.dirが不良ですか？）
  • 54：ExternalBlockStoreは多くの試行後に初期化に失敗しました
  • 55：ExternalBlockStoreは、多くの試行の後、ローカル一時ディレクトリの作成に失敗しました

  • 56：エグゼキューターは、「spark.executor.heartbeat.maxFailures」回を超えてドライバーにハートビートを送信できません。

  • 101：子メインクラスが見つからなかった場合、spark-submitによって返されます。クライアントモード（コマンドラインオプション_--deploy-mode client_）では、子メインクラスはユーザーが送信したアプリケーションクラス（_--class CLASS_）です。クラスターモード（_--deploy-mode cluster_）では、子メインクラスはクラスターマネージャー固有の送信/クライアントクラスです。

128より大きい終了コード

これらの終了コードは、Unixシグナルによってトリガーされたプログラムのシャットダウンが原因である可能性があります。シグナル番号は、終了コードから128を引くことで計算できます。これについては、この ブログ投稿 （元々 この質問 にリンクされていました）で詳しく説明されています。また、優れた JVMで生成された終了コードの説明 もあります。 Sparkは ExecutorExitCodes.scala）のコメントで説明されているように、この仮定で機能します

その他の終了コード

上記の終了コードとは別に、終了コードとして1または-1を設定するSpark sources）にはSystem.exit()呼び出しの数があります。 1が他のすべてのエラーを示すのに対し、コマンドラインパラメーターが欠落しているか正しくないことを示すために使用されます。

信号

シグナルは、システムメッセージをプロセスに送信できるイベントの一種です。これらのメッセージは、たとえば、プロセスに構成の再読み込み（SIGHUP）を要求したり、プロセス自体を終了（SIGKILL）したりするために使用されます。標準シグナルのリストは、セクション標準シグナルの signal（7）manページ にあります。

以下のコメントでRick Moritzが説明したように（ありがとう！）、Sparkセットアップで最も可能性の高い信号源は

  • クラスタリソースマネージャコンテナサイズを超えたとき、ジョブが終了したとき、動的な縮小が行われたとき、またはユーザーによってジョブが中止されたとき
  • オペレーティングシステム：制御されたシステムのシャットダウンの一部として、または何らかのリソース制限に達した場合（メモリ不足、ハードクォータを超え、ディスクにスペースが残っていないなど）
  • ジョブを殺したlocal user

これにより、sparkによるこれらのメッセージの意味が少し明確になることを願っています。

47
Christoph Böhme