在CDH-5.10.2上的RSparkling中发送批量UDP字节时连续出现“IO IO错误:java.net.ConnectException:Connection refused”

时间:2017-09-07 17:40:12

标签: r cloudera-cdh h2o sparklyr sparkling-water

我正在尝试在脱机CDH-5.10.2群集上执行this RSparkling example。我的环境是:

  • Spark 1.6.0;
  • sparklyr 0.6.2;
  • h2o 3.10.5.2;
  • rsparkling 0.2.1。

我使用自定义的Sparkling Water JAR,基本上是1.6.12且应用了this PR

options(rsparkling.sparklingwater.location = "/opt/h2o/sparkling-water-1.6.13-SNAPSHOT/assembly/build/libs/sparkling-water-assembly_2.10-1.6.13-SNAPSHOT-all.jar")

成功连接后:

config <- spark_config()
config$spark.dynamicAllocation.enabled <- "false"
config$spark.driver.memory <- "6g"
config$spark.executor.memory <- "6g"
config$spark.executor.heartbeatInterval <- "20s"

sc <- spark_connect(master = "yarn-client", config = config)

我创建了H2O上下文:

h2o_context(sc)

H2O上下文创建需要几分钟(这是第一个奇怪的事情)。

创建后,应用程序将在几分钟后无响应(甚至Spark master UI也无法访问)。此时不打印H2O日志。

之后,会出现H2O日志,但它们主要包含以下消息:

Got IO error when sending batch UDP bytes: java.net.ConnectException: Connection refused

并且这些之间很少见:

WARN: Unblock allocations; cache below desired, but also OOM: OOM, (K/V:Zero   + POJO:661.8 MB + FREE:306.7 MB == MEM_MAX:968.5 MB), desiredKV=121.1 MB OOM!

然后快速执行以下与H2O无关的代码:

flights_tbl <- copy_to(sc, nycflights13::flights, "flights")
airports_tbl <- copy_to(sc, nycflights13::airports, "airports")
airlines_tbl <- copy_to(sc, nycflights13::airlines, "airlines")
model_tbl <- flights_tbl %>%
  filter(!is.na(arr_delay) & !is.na(dep_delay) & !is.na(distance)) %>%
  filter(dep_delay > 15 & dep_delay < 240) %>%
  filter(arr_delay > -60 & arr_delay < 360) %>%
  left_join(airlines_tbl, by = c("carrier" = "carrier")) %>%
  mutate(gain = dep_delay - arr_delay) %>%
  select(origin, dest, carrier, airline = name, distance, dep_delay, arr_delay, gain)

但是当H2O必须再次发挥作用时:

df_hex <- as_h2o_frame(sc,model_tbl,name="model_hex",FALSE)

应用程序再次挂起(到目前为止,它已经悬挂了大约20分钟左右)。

我尝试多次重新运行此代码并成功一次但通常它只是挂起。如何解决这个问题?

我检查了CPU,RAM和磁盘使用情况,所有这些似乎没问题。也没有明显的网络问题。

更新1 。也许ConnectException只是K/V:Zero + POJO:661.8 MB + FREE:306.7 MB == MEM_MAX:968.5 MB的结果。因此,我将尝试找出如何增加H2O的最大内存(以及为什么它首先低于1 GB)。

1 个答案:

答案 0 :(得分:0)

根本原因是sparklyr的内存分配不足,默认的1 GB内存对于在同一JVM中执行的H2O客户端来说是不够的。这些代码行节省了一天:

config$`sparklyr.shell.driver-memory` <- "6g"
config$`sparklyr.shell.executor-memory` <- "6g"