加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 综合聚焦 > 服务器 > 安全 > 正文

scala – 关于小数据大小与可用内存的Executor OutOfMemoryExcep

发布时间:2020-12-16 19:23:48 所属栏目:安全 来源:网络整理
导读:给出一个简单的案例类 case class Rating(user: Int,item: Int,rating: Double) 和两个RDD [评级]:我们正在获得OOME的两个RDD之间大约700万个条目. 我们配置了一个带有30.4GB RAM的单个执行程序.这是每个评级条目的巨大开销.我无法证明这一点:Int和Double
给出一个简单的案例类

case class Rating(user: Int,item: Int,rating: Double)

和两个RDD [评级]:我们正在获得OOME的两个RDD之间大约700万个条目.

我们配置了一个带有30.4GB RAM的单个执行程序.这是每个评级条目的巨大开销.我无法证明这一点:Int和Double的原始基元在64位平台上是8个字节.然后将有相同的Java表示和Case类的开销.但是所有人都告诉我们应该仍然是< JVM中单个Rating条目的200字节. 给定30.4GB RAM和7M对象 – 那么每个对象的表观内存使用量将超过4KB.这不算. 以下是单个执行程序显示30.4GB的集群和作业信息:

enter image description here

请注意,我们还通过在KryoSerializer中注册Rating类并启用了kryo序列化

spark.rdd.compress=true

这些并没有影响到OOME的.

RDD表示是否会增加内存使用量?或者是大多数执行程序RAM根本没有被使用的问题 – 由于其他一些原因,OOME正在发生?

这是由此产生的OOME – 只需几秒即可完成工作:

[Dec 06 22:37:32] Generated an implicit feedback dataset with 4501305 ratings for training and 2247105 for test.
Generated dataset in 2644ms
[Stage 0:>                                                          (0 + 1) / 2]Exception in thread "dispatcher-event-loop-5" java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Arrays.java:2271)
    at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:118)
    at java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)
    at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:153)
    at java.io.ObjectOutputStream$BlockDataOutputStream.write(ObjectOutputStream.java:1852)
    at java.io.ObjectOutputStream.write(ObjectOutputStream.java:708)
    at java.nio.channels.Channels$WritableByteChannelImpl.write(Channels.java:458)
    at org.apache.spark.util.SerializableBuffer$$anonfun$writeObject$1.apply(SerializableBuffer.scala:49)
    at org.apache.spark.util.SerializableBuffer$$anonfun$writeObject$1.apply(SerializableBuffer.scala:47)
    at org.apache.spark.util.Utils$.tryOrIOException(Utils.scala:1219)
    at org.apache.spark.util.SerializableBuffer.writeObject(SerializableBuffer.scala:47)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
    at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1495)
    at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1431)
    at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1177)
    at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1547)
    at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1508)
    at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1431)
    at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1177)
    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
    at org.apache.spark.serializer.JavaSerializationStream.writeObject(JavaSerializer.scala:44)
    at org.apache.spark.serializer.JavaSerializerInstance.serialize(JavaSerializer.scala:101)
    at org.apache.spark.scheduler.cluster.CoarseGrainedSchedulerBackend$DriverEndpoint$$anonfun$launchTasks$1.apply(CoarseGrainedSchedulerBackend.scala:226)
    at org.apache.spark.scheduler.cluster.CoarseGrainedSchedulerBackend$DriverEndpoint$$anonfun$launchTasks$1.apply(CoarseGrainedSchedulerBackend.scala:225)
    at scala.collection.immutable.List.foreach(List.scala:318)
    at org.apache.spark.scheduler.cluster.CoarseGrainedSchedulerBackend$DriverEndpoint.launchTasks(CoarseGrainedSchedulerBackend.scala:225)
    at org.apache.spark.scheduler.cluster.CoarseGrainedSchedulerBackend$DriverEndpoint.org$apache$spark$scheduler$cluster$CoarseGrainedSchedulerBackend$DriverEndpoint$$makeOffers(CoarseGrainedSchedulerBackend.scala:196)
    at org.apache.spark.scheduler.cluster.CoarseGrainedSchedulerBackend$DriverEndpoint$$anonfun$receive$1.applyOrElse(CoarseGrainedSchedulerBackend.scala:123)

注意:如果我们使用的数据略少 – 例如如果RDD具有500万个评级,则作业相对较快地完成(<40秒)并且成功完成. 因此,我们不确定哪些因素限制了火花工作者对这种低内存约束的有用性.

解决方法

问题的大部分似乎是DRIVER程序需要的RAM远远超过预期.

Driver程序没有进行任何收集,take,groupBy等,但只计数.不确定为什么count需要驱动程序上的大量资源.在我们缩小驱动程序详细信息时,将在此处添加更多详细信息.

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读