发现没有 H2O 实例的执行器,杀死云

Executor without H2O instance discovered, killing the cloud

我是 运行 Tweedie GLM,使用苏打水处理不同大小的数据,即 20 MB、400 MB、2GB、25 GB。代码适用于 采样迭代 10。但是我必须测试大样本场景..

Sampling iteration is 500 

在这种情况下,代码适用于 20 和 400 MB data.But 当数据大于 2 GB 时它开始抛出问题

搜索后我找到了一种禁用更改侦听器的解决方案,但它不适用于大数据。
--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 \
        \
        \
        --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.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$$anonfun$run.apply$mcV$sp(AsynchronousListenerBus.scala:79)
            at org.apache.spark.util.Utils$.tryOrStopSparkContext(Utils.scala:1136)
            at org.apache.spark.util.AsynchronousListenerBus$$anon.run(AsynchronousListenerBus.scala:63)

我会使用苏打水 shell 并一次执行一行来解决这个问题

  • 开始shell
  • 开始H2O
  • 监控集群状态

然后

  1. 读取输入数据并缓存它
  2. 阅读 Yarn 日志以了解为什么我的任务被杀死,很多时候 Yarn 抢占会杀死执行者。
  3. 增加启动 H2O 进程的 Spark 等待时间
  4. 将执行程序的数量减少到 3 个/将内核增加到 3 个/将执行程序内存增加到 6 GB
  5. 监控 Spark UI 和 H2O Flow UI 以查看每个阶段的内存情况

作为一般规则,H2O 集群的内存大小应为数据输入大小的 5 倍。每次迭代你都超过了这个限制吗? 2 GB 似乎很小。我们每天使用苏打水和 Spark 处理大量数据。

H2o网站上有一些建议

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

仔细阅读 github https://github.com/h2oai/sparkling-water/issues/32 上发布的问题。我尝试了几个选项,这里是我尝试过的
已添加
--conf "spark.scheduler.minRegisteredResourcesRatio=1" "spark.ext.h2o.topology.change.listener.enabled=false" "spark.locality.wait=3000" "spark.ext.h2o.network.mask=10.196.64.0/24"

Changed the :

Executors from 10 to 3,6 9
executor-memory from 4 to 12 and 12 to 24gb
driver-memory from 4 to 12 and 12 to 24gb

这是我了解到的:GLM 是内存密集型作业,因此我们必须提供足够的内存来执行该作业。