スパーククラスタ、自分の

Question

私のApacheのスパーククラスタは私にエグゼキュータのタイムアウトの多くを与えているアプリケーションを実行しているに出執行：

10:23:30,761 ERROR ~ Lost executor 5 on slave2.cluster: Executor heartbeat timed out after 177005 ms 
10:23:30,806 ERROR ~ Lost executor 1 on slave4.cluster: Executor heartbeat timed out after 176991 ms 
10:23:30,812 ERROR ~ Lost executor 4 on slave6.cluster: Executor heartbeat timed out after 176981 ms 
10:23:30,816 ERROR ~ Lost executor 6 on slave3.cluster: Executor heartbeat timed out after 176984 ms 
10:23:30,820 ERROR ~ Lost executor 0 on slave5.cluster: Executor heartbeat timed out after 177004 ms 
10:23:30,835 ERROR ~ Lost executor 3 on slave7.cluster: Executor heartbeat timed out after 176982 ms 

しかし、私の構成では、私は私が正常に増加を確認することができますエグゼキュータのハートビート間隔：

私はEXITEDとしてマークされたエグゼキュータのログを訪れる （すなわち：それはハートビートを得ることができなかったときに、ドライバはそれらを削除）、彼らが受け取っていないので、執行が自分自身を殺したことが表示されますドライバーからの任意のタスク：

16/05/16 10:11:26 ERROR TransportChannelHandler: Connection to /10.0.0.4:35328 has been quiet for 120000 ms while there are outstanding requests. Assuming connection is dead; please adjust spark.network.timeout if this is wrong. 
16/05/16 10:11:26 ERROR CoarseGrainedExecutorBackend: Cannot register with driver: spark://CoarseGrainedScheduler@10.0.0.4:35328 

ハートビートをオフにしたり、エグゼキュータのタイムアウトを防ぐにはどうすればよいですか？

Answer 1

答えはやや単純でした。私のspark-defaults.confでは、spark.network.timeoutをより高い値に設定しました。ハートビートの間隔は問題には関係ありませんでした（チューニングは便利ですが）。​​を使用して、私はまた、次のようにタイムアウトを設定することができました

：YARNによって殺されて

$SPARK_HOME/bin/spark-submit --conf spark.network.timeout 10000000 --class myclass.neuralnet.TrainNetSpark --master spark://master.cluster:7077 --driver-memory 30G --executor-memory 14G --num-executors 7 --executor-cores 8 --conf spark.driver.maxResultSize=4g --conf spark.executor.heartbeatInterval=10000000 path/to/my.jar 

Answer 2

欠落ハートビートと執行は、ほぼ常にOOMsによるものです。個々のエグゼキュータのログを調べる必要があります（「物理メモリを超えて実行する」というテキストを参照）。エグゼキュータが多く、すべてのログを手動で検査するのが面倒な場合は、実行中にSpark UIでジョブを監視することをお勧めします。タスクが失敗するとすぐに、UIに原因を報告するので、見やすくなります。一部のタスクでは、すでにエスケープされていないエグゼキュータが見つからないために失敗が報告されるため、個々の失敗したタスクの原因を確認してください。

ほとんどのOOMの問題は、コード内の適切な場所でデータを再分割するだけで簡単に解決できます（また、repartitionへの呼び出しの必要性に関するヒントについては、Spark UIを参照してください）。それ以外の場合は、メモリの必要性に合わせてマシンをスケールアップすることもできます。