SparkR收集方法在Java堆空间上使用OutOfMemory崩溃

Question

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

我的Spark群集在Google Cloud中运行，并且由bdutil进行部署，由1个主服务器和2个工作服务器组成，每个服务器有15GB的RAM和4个内核。我的HDFS存储库基于带有gcs-connector 1.4.0的Google Storage。在每台机器上安装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中永远不会返回？

我使用谷歌搜索的每一条信息，但我没有找到解决方法。任何帮助或提示将不胜感激！

由于

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的表明它使用〜RES内存1.7克。我抓起另一个堆转储。最后，我还尝试test <- {}以摆脱允许垃圾收集的引用。这样做后，打印出test并显示它是空的，我抓起另一个堆转储，并注意到RES仍然显示1.7克。我以前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，它基本保持不变。这向我们展示了char []的2784858个实例，总大小为579MB，并且还显示了2782732个String实例，大概在它上面保存了这些char []。我跟着参考图形一直向上，并得到类似于

char [] - > String - > String [] - > ... - > class scala.collection.mutable.DefaultEntry - > class [Lscala。 collection.mutable.HashEntry; - > class scala.collection.mutable.HashMap - > class edu.berkeley.cs.amplab.sparkr.JVMObjectTracker $ - > java.util.Vector@0x785b48cd8（36 bytes） - > sun.misc.Launcher$AppClassLoader@0x7855c31a8（ 138字节）

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

最后，要回答关于在collect之后挂起的问题，看起来它与R进程内存中不适合的数据有关;这里是一个与此问题有关的线程：https://www.mail-archive.com/user@spark.apache.org/msg29155.html

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