疑似分散モードでは発生するが、スタンドアロン モードでは発生しない問題があります。これをデバッグする方法についていくつかのアイデアを練り上げたいと思っています。
私のマッパー タスクの一部がコード 143 を返しています。System.exit() にブレークポイントをドロップして、誰がなぜこれを呼び出しているかを確認したいのですが、そのマッパーでデバッガーを実行する必要があります。
bin/hadoop スクリプトを変更し、localhost:5000 にリモート接続することで、デバッガーでタスク トラッカーを起動できます。
...
elif [ "$COMMAND" = "tasktracker" ] ; then
CLASS=org.apache.hadoop.mapred.TaskTracker
HADOOP_OPTS="$HADOOP_OPTS $HADOOP_TASKTRACKER_OPTS"
# TBMark!
HADOOP_OPTS="$HADOOP_OPTS -Xdebug -Xrunjdwp:transport=dt_socket,address=5000,server=y,suspend=n"
...そして、これを conf/mapred-site.xml に追加し、localhost:5001 にリモート接続することで、Eclipse に最初のマッパー (または微調整、リデューサー) を取得できます。
<property>
<name>mapred.map.child.java.opts</name>
<value>-Xdebug -Xrunjdwp:transport=dt_socket,address=5001,server=y,suspend=y</value>
</property>
私の問題は、障害が最初のマッパーではなくランダムに発生することです。
頭に浮かぶ不満足なアイデアには、次のものがあります。
- どういうわけか System.exit() をスタック トレースを行う独自のメソッドに置き換えます。(システムコールをフックするにはどうすればよいですか?)
- マッパーを 1 つずつデバッグし、それぞれを最後まで実行してから次のデバッグを行ってください。(効くかも…)
- System.exit() を呼び出す Hadoop の最後の場所をすべて追跡し、個別の署名をログに書き込みます。(うん)
- デバッガーのポート番号変数を作成して、どちらが失敗するかを推測でき、遅延によってバグが解消されない場合は、その jvm にアタッチしてデバッグできるようにします。(多くの if があり、.xml ファイルでこの変数を作成する方法がわかりません。)
- 特定の試行で失敗が予測される場合は、jvm を起動する直前にタスク トラッカーを中断し、スクリプト ファイルを手動で編集します。(絶望的な時代には絶望的な措置が必要です)
上記の私の悪いアイデアを機能させる方法についての提案やアイデアはありますか?