1

20 MB、400 MB、2 GB、25 GB など、さまざまなサイズのデータ​​に炭酸水を使用して Tweedie GLM を実行しています。コードはSampling iteration 10で正常に動作します。しかし、大規模なサンプリングシナリオをテストする必要があります..

サンプリング反復は 500 です

この場合、コードは 20 および 400 mb のデータに対して適切に機能しますが、データが 2 GB を超えると問題が発生し始めます。

検索を行った後、変更リスナーを無効にするソリューションが1つ見つかりましたが、それは大きなデータでは機能しませんでした。
--conf "spark.scheduler.minRegisteredResourcesRatio=1" "spark.ext.h2o.topology.change.listener.enabled=false"

これが私のspark送信構成です

spark-submit \
     --packages  ai.h2o:sparkling-water-core_2.10:1.6.1, log4j:log4j:1.2.17\
        --driver-memory 8g \
        --executor-memory 10g \
        --num-executors 10\
        --executor-cores 5 \
        --class TweedieGLM  target/SparklingWaterGLM.jar \
        $1\
        $2\
        --conf "spark.scheduler.minRegisteredResourcesRatio=1" "spark.ext.h2o.topology.change.listener.enabled=false"

これは私がエラーとして得たものです

16/07/08 20:39:55 ERROR YarnScheduler: Lost executor 2 on cfclbv0152.us2.oraclecloud.com: Executor heartbeat timed out after 175455 ms
    16/07/08 20:40:00 ERROR YarnScheduler: Lost executor 2 on cfclbv0152.us2.oraclecloud.com: remote Rpc client disassociated
    16/07/08 20:40:00 ERROR LiveListenerBus: Listener anon1 threw an exception
    java.lang.IllegalArgumentException: Executor without H2O instance discovered, killing the cloud!
            at org.apache.spark.h2o.H2OContext$$anon$1.onExecutorAdded(H2OContext.scala:203)
            at org.apache.spark.scheduler.SparkListenerBus$class.onPostEvent(SparkListenerBus.scala:58)
            at org.apache.spark.scheduler.LiveListenerBus.onPostEvent(LiveListenerBus.scala:31)
            at org.apache.spark.scheduler.LiveListenerBus.onPostEvent(LiveListenerBus.scala:31)
            at org.apache.spark.util.ListenerBus$class.postToAll(ListenerBus.scala:56)
            at org.apache.spark.util.AsynchronousListenerBus.postToAll(AsynchronousListenerBus.scala:37)
            at org.apache.spark.util.AsynchronousListenerBus$$anon$1$$anonfun$run$1.apply$mcV$sp(AsynchronousListenerBus.scala:79)
            at org.apache.spark.util.Utils$.tryOrStopSparkContext(Utils.scala:1136)
            at org.apache.spark.util.AsynchronousListenerBus$$anon$1.run(AsynchronousListenerBus.scala:63)
4

2 に答える 2

0

Sparkling water shell を使用し、一度に 1 行ずつ実行して、この問題のトラブルシューティングを行います。

  • シェルを起動
  • H2Oを開始
  • クラスターの状態を監視する

それで

  1. 入力データを読み取ってキャッシュする
  2. Yarn のログを読んで、タスクが kill されている理由を見つけてください。多くの場合、Yarn のプリエンプションによってエグゼキューターが強制終了されます。
  3. H2O プロセスを開始するための Spark 待機時間の増加
  4. エグゼキュータの数をわずか 3 に減らす / コアを 3 に増やす / エグゼキュータのメモリを 6 GB に増やす
  5. Spark UI と H2O Flow UI を監視して、各ステージでメモリに何が起こっているかを確認します

原則として、H2O クラスターのメモリ サイズは、データ入力サイズの 5 倍にする必要があります。反復ごとに、その限界を超えていますか? 2 GB は非常に小さいようです。スパークリングウォーターとスパークを使用して、毎日大量の処理を行っています。

H2oのウェブサイトにいくつかの提案があります

https://github.com/h2oai/sparkling-water/blob/master/doc/configuration/internal_backend_tuning.rst

于 2016-07-09T03:33:50.850 に答える