Question

使用SparkR，我正在尝试使用PoC来收集我从包含大约4M行的文本文件创建的RDD。

My Spark集群在Google Cloud中运行，由bdutil部署，由1个主服务器和2个工作人员组成，每个服务器具有15GB内存和4个内核。我的HDFS存储库基于带有gcs-connector 1.4.0的Google存储。 SparkR安装在每台机器上，基本测试用于处理小文件。

这是我使用的脚本：

Sys.setenv("SPARK_MEM" = "1g")
sc <- sparkR.init("spark://xxxx:7077", sparkEnvir=list(spark.executor.memory="1g"))
lines <- textFile(sc, "gs://xxxx/dir/")
test <- collect(lines)

我第一次运行它，似乎工作正常，所有任务都成功运行，火花＆ui说工作已经完成，但我从未得到R提示：

15/06/04 13:36:59 WARN SparkConf: Setting 'spark.executor.extraClassPath' to ':/home/hadoop/hadoop-install/lib/gcs-connector-1.4.0-hadoop1.jar' as a work-around.
15/06/04 13:36:59 WARN SparkConf: Setting 'spark.driver.extraClassPath' to ':/home/hadoop/hadoop-install/lib/gcs-connector-1.4.0-hadoop1.jar' as a work-around.
15/06/04 13:36:59 INFO Slf4jLogger: Slf4jLogger started
15/06/04 13:37:00 INFO Server: jetty-8.y.z-SNAPSHOT
15/06/04 13:37:00 INFO AbstractConnector: Started SocketConnector@0.0.0.0:52439
15/06/04 13:37:00 INFO Server: jetty-8.y.z-SNAPSHOT
15/06/04 13:37:00 INFO AbstractConnector: Started SelectChannelConnector@0.0.0.0:4040

15/06/04 13:37:54 INFO GoogleHadoopFileSystemBase: GHFS version: 1.4.0-hadoop1
15/06/04 13:37:55 WARN LoadSnappy: Snappy native library is available
15/06/04 13:37:55 WARN NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
15/06/04 13:37:55 WARN LoadSnappy: Snappy native library not loaded
15/06/04 13:37:55 INFO FileInputFormat: Total input paths to process : 68
[Stage 0:=======================================================>                                                                                     (27 + 10) / 68]

然后在CTRL-C之后得到R提示符，我尝试再次运行collect方法，结果如下：

[Stage 1:==========================================================>                                                                                   (28 + 9) / 68]15/06/04 13:42:08 ERROR ActorSystemImpl: Uncaught fatal error from thread [sparkDriver-akka.remote.default-remote-dispatcher-5] shutting down ActorSystem [sparkDriver]
java.lang.OutOfMemoryError: Java heap space
        at org.spark_project.protobuf.ByteString.toByteArray(ByteString.java:515)
        at akka.remote.serialization.MessageContainerSerializer.fromBinary(MessageContainerSerializer.scala:64)
        at akka.serialization.Serialization$$anonfun$deserialize$1.apply(Serialization.scala:104)
        at scala.util.Try$.apply(Try.scala:161)
        at akka.serialization.Serialization.deserialize(Serialization.scala:98)
        at akka.remote.MessageSerializer$.deserialize(MessageSerializer.scala:23)
        at akka.remote.DefaultMessageDispatcher.payload$lzycompute$1(Endpoint.scala:58)
        at akka.remote.DefaultMessageDispatcher.payload$1(Endpoint.scala:58)
        at akka.remote.DefaultMessageDispatcher.dispatch(Endpoint.scala:76)
        at akka.remote.EndpointReader$$anonfun$receive$2.applyOrElse(Endpoint.scala:937)
        at akka.actor.Actor$class.aroundReceive(Actor.scala:465)
        at akka.remote.EndpointActor.aroundReceive(Endpoint.scala:415)
        at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516)
        at akka.actor.ActorCell.invoke(ActorCell.scala:487)
        at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:238)
        at akka.dispatch.Mailbox.run(Mailbox.scala:220)
        at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:393)
        at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
        at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
        at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
        at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)

我理解异常消息，但我不明白为什么我第二次得到这个消息。另外，为什么收集在Spark完成后永远不会返回？

我用Google搜索了我的每一条信息，但我没有找到解决方案的运气。任何帮助或提示将不胜感激！

由于

Answer 1

这看起来似乎是Java内存中对象表示的低效组合与一些明显的长期对象引用的简单组合，这些引用导致某些集合无法及时被垃圾收集以用于新的collect（）调用原地覆盖旧的。

我尝试了一些选项，对于包含~4M行的样本256MB文件，我确实重现了第一次收集很好的行为，但是在使用SPARK_MEM=1g时第二次是OOM。然后我设置了SPARK_MEM=4g，然后我可以按ctrl + c重新运行test <- collect(lines)。

首先，即使引用没有泄漏，请注意在第一次运行test <- collect(lines)之后，变量test正在保持那个巨大的行数，第二次你调用它，collect(lines)在最终被分配给test变量之前执行，因此在任何简单的指令排序中，没有办法进行垃圾收集test的旧内容。这意味着第二次运行将使SparkRBackend进程同时保存整个集合的两个副本，从而导致您看到的OOM。

要诊断，在主人上我开始使用SparkR并首先运行

dhuo@dhuo-sparkr-m:~$ jps | grep SparkRBackend 8709 SparkRBackend

我还检查了top，它使用了大约22MB的内存。我用jmap：
获取了一个堆配置文件
jmap -heap:format=b 8709 mv heap.bin heap0.bin

然后我运行第一轮test <- collect(lines)，此时运行top使用~1.7g的RES内存显示它。我抓住了另一个堆转储。最后，我还尝试test <- {}去掉允许垃圾收集的引用。执行此操作后，打印出test并将其显示为空，我抓住另一个堆转储并注意到RES仍显示1.7g。我使用jhat heap0.bin来分析原始堆转储，并得到：

Heap Histogram All Classes (excluding platform) Class Instance Count Total Size class [B 25126 14174163 class [C 19183 1576884 class [<other> 11841 1067424 class [Lscala.concurrent.forkjoin.ForkJoinTask; 16 1048832 class [I 1524 769384 ...

运行收集后，我有：

Heap Histogram All Classes (excluding platform) Class Instance Count Total Size class [C 2784858 579458804 class [B 27768 70519801 class java.lang.String 2782732 44523712 class [Ljava.lang.Object; 2567 22380840 class [I 1538 8460152 class [Lscala.concurrent.forkjoin.ForkJoinTask; 27 1769904

即使在我test之后，它仍然大致相同。这向我们展示了2784858个char []的实例，总大小为579MB，还有2782732个String实例，可能在它上面持有那些char []。我一直跟着参考图，并得到像
这样的东西
char [] - ＆gt;字符串 - ＆gt; String [] - ＆gt; ... - ＆gt; class scala.collection.mutable.DefaultEntry - ＆gt; class [Lscala.collection.mutable.HashEntry; - ＆GT; class scala.collection.mutable.HashMap - ＆gt; class edu.berkeley.cs.amplab.sparkr.JVMObjectTracker $ - ＆gt; java.util.Vector@0x785b48cd8（36字节） - ＆gt; sun.misc.Launcher$AppClassLoader@0x7855c31a8（138 bytes）

然后AppClassLoader有成千上万的入站引用。所以在这个链条的某个地方应该删除他们的引用，但是没有这样做，导致整个收集的数组在我们尝试获取它的第二个副本时就坐在内存中。

最后，要回答关于在collect之后悬挂的问题，它似乎与不适合R进程内存的数据有关;这是与该问题相关的主题：https://www.mail-archive.com/user@spark.apache.org/msg29155.html

我确认使用只有少数行的较小文件，然后运行collect确实不会挂起。

SparkR collect方法在Java堆空间上与OutOfMemory崩溃

1 个答案: