spark java.lang.StackOverflowError

问题描述

在工作中使用spark的一个主要内容就是从多个路径下搜集数据并进行处理。常用的代码大致如下:

    val paths = obtainPaths()
    val rdd = paths.map(readData).reduce(_ ++ _)
    val arr = rdd.collect()

在readData方法中调用SparkContext的sequenceFile方法读取文件创建RDD集合。而后调用RDD的reduce和union(即“++”)方法将多个RDD集合进行合并。

这里的代码通常是不会报错的。但是执行合并后的RDD集合的Action算子(这里是collect方法)的时候偶尔会遇到StackOverflowError。异常信息如下:

18/06/29 17:23:14 ERROR executor.Executor: Exception in task 28.0 in stage 0.0 (TID 28)
java.lang.StackOverflowError
        at java.lang.Exception.<init>(Exception.java:102)
        at java.lang.ReflectiveOperationException.<init>(ReflectiveOperationException.java:89)
        at java.lang.reflect.InvocationTargetException.<init>(InvocationTargetException.java:72)
        at sun.reflect.GeneratedSerializationConstructorAccessor13.newInstance(Unknown Source)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
        at java.io.ObjectStreamClass.newInstance(ObjectStreamClass.java:967)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1782)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
        at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1706)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1344)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)

从异常信息上来看,是在使用java.io.ObjectInputStream执行序列化的时候出现了递归或者死循环,因为栈空间不足导致的这个问题。

继续跟踪调试,发现主要是因为处理的文件过多导致的——一般处理的文件数量超过450(大致数值)以后就会遇到这个问题。查了一些资料,了解到根本原因是RDD Lineage过长:代码中每执行一次RDD.union操作就会增加一次RDD Lineage的步长。

解决问题

现在根据问题的特征和根源,找到的解决思路大致上有这么几个:

  1. 增加执行时的栈空间;
  2. 避免一次处理过多文件;
  3. 定期削减RDD Lineage的长度;
  4. 避免创建太长的Lineage。

接下来逐个解释下上面的思路。

增加栈空间

从异常信息中可以看到StatckOverflowError是在Executor中抛出的,所以要调整Executor栈空间,可以在job提交参数中添加如下内容:

--conf spark.executor.extraJavaOptions="-Xss80M "

这项配置将Executor的栈空间设置为80M。

然后我们测试一下,测试目标是一次处理720个文件。执行结果OK。

再次测试,仍然是80M栈空间,目标一次处理4320个文件。仍然能执行成功。

可知这个方案在一定程度上是可行的,至少可以用来做任务优化。

避免一次处理过多的文件

这个思路是最简单的:既然一次处理太多文件会报错,那么就分成多个批次来处理好了。

调整后的代码如下:

    val paths = obtainPaths()
 
    val pathItr = paths.grouped(360)
 
    val buffer = ListBuffer[String]()
    
    for (p <- pathItr) {
      val list =  paths.map(readData).reduce(_ ++ _).collect().toList
      buffer ++= list
    }

这种方式肯定是可行的,但是用起来多少有点儿麻烦:需要将中间结果集临时存储起来而后再一起使用。中间结果集要是比较小的话还好说,一个变量就足够了;中间结果集要是太大了就得先保存到HDFS上,而后再做二次处理。

削减RDD Lineage的长度

既然问题是因为RDD Lineage长度过长导致的,那么就需要在RDD Lineage变得太长之前,将之削减掉一部分。做法是对合并出的RDD结果集定期做checkpoint,并随意执行一个Action算子。

代码如下:

    val paths = obtainPaths()
 
    val count = new AtomicInteger(0)
    val arr = paths.map(readData).fold(sc.emptyRDD[String]) {
      (a, b) => {
        if(count.getAndIncrement() % 360 == 0){
          a.checkpoint()
          a.collect()
        }
        a ++ b
      }
    }.collect()

我一度依赖过这个方案。但是这个方案有一个很大的缺点:就是执行效率太低——比上一种方案效率还低,可以说是执行时间最慢的一种方式了。checkpoint操作实际上是将每个rdd都存储到了硬盘上,其效率可想而知。

避免创建太长的Lineage

前面说的第二种方式也可以说是这种思路的实现。对这个问题来说,推荐得比较多的还是使用SparkContext.union方法来替换RDD.union方法。代码大致如下:

    val paths = obtainPaths()
 
    val arr = sc.union(paths.map(readData)).collect()

这个方式也是我最初寄望最多的一个方案。

本来希望能通过这个方案一劳永逸地解决这个问题。可是在测试的时候遇到了些问题:这个方案也不能处理路径太多(800个以上)的问题,但是也没有立即报错,而是阻塞住了。执行两三个小时后提示任务执行失败。在日志中可以找到如下错误提示:

18/07/01 14:48:02 INFO storage.BlockManagerMaster: Registered BlockManager
18/07/01 15:00:33 WARN netty.NettyRpcEndpointRef: Error sending message [message = Heartbeat(2,[Lscala.Tuple2;@40fe6823,BlockManagerId(2, 172.18.12.197, 44839))] in 1 attempts
org.apache.spark.rpc.RpcTimeoutException: Futures timed out after [10 seconds]. This timeout is controlled by spark.executor.heartbeatInterval
        at org.apache.spark.rpc.RpcTimeout.org$apache$spark$rpc$RpcTimeout$$createRpcTimeoutException(RpcTimeout.scala:48)
        at org.apache.spark.rpc.RpcTimeout$$anonfun$addMessageIfTimeout$1.applyOrElse(RpcTimeout.scala:63)
        at org.apache.spark.rpc.RpcTimeout$$anonfun$addMessageIfTimeout$1.applyOrElse(RpcTimeout.scala:59)
        at scala.runtime.AbstractPartialFunction.apply(AbstractPartialFunction.scala:33)
        at org.apache.spark.rpc.RpcTimeout.awaitResult(RpcTimeout.scala:76)
        at org.apache.spark.rpc.RpcEndpointRef.askWithRetry(RpcEndpointRef.scala:101)
        at org.apache.spark.executor.Executor.org$apache$spark$executor$Executor$$reportHeartBeat(Executor.scala:449)
        at org.apache.spark.executor.Executor$$anon$1$$anonfun$run$1.apply$mcV$sp(Executor.scala:470)
        at org.apache.spark.executor.Executor$$anon$1$$anonfun$run$1.apply(Executor.scala:470)
        at org.apache.spark.executor.Executor$$anon$1$$anonfun$run$1.apply(Executor.scala:470)

对于这个错误提示我目前并无头绪,只能先抛出来给大家看一下。以后如果有进展再继续补充。

就这样。

参考文档:

  • http://apache-spark-user-list.1001560.n3.nabble.com/java-lang-StackOverflowError-when-calling-count-td5649.html

  • https://stackoverflow.com/questions/30522564/spark-when-union-a-lot-of-rdd-throws-stack-overflow-error

  • https://stackoverflow.com/questions/38206166/apache-spark-stackoverflowerror-when-trying-to-indexing-string-columns

#####

原文 

http://www.zhyea.com/2018/07/02/spark-java-lang-stackoverflowerror.html

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » spark java.lang.StackOverflowError

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址