2016-12-07 6 views
4

は、単純なケースクラスエグゼキュータOutOfMemoryExceptions

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

と2 RDD[Rating]を考えます。

エグゼキュータを30.4GB RAMで構成しました。それはそれぞれ巨大なのオーバーヘッドであり、それぞれエントリです。私はそれを正当化することはできません:IntとDoubleの生のプリミティブは、64ビットプラットフォームでは8バイトです。それから、同じクラスのJava表現とCaseクラスのオーバーヘッドが発生します。しかし、すべての人は、RatingのJVM内の1つのエントリに対して、まだ<の200バイトでなければならないと話しました。

30.4GBのRAMと7Mのオブジェクトを指定すると、見かけ上のメモリ使用量はオブジェクトあたり4KB以上になります。それは計算されません。我々はまた、KryoSerializerRatingクラスを登録することでkryoシリアライズを有効にして

spark.rdd.compress=true 
を有効にしている

enter image description here

注:ここでは

は、単一のエグゼキュータのための30.4ギガバイトを示すクラスタとジョブの情報です

これらは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万Ratingの場合、ジョブは比較的速く完了し(< 40秒)、正常に完了します。

私たちは、どのような要因がスパーク作業員のこのような低いメモリ制約への有用性を制限しているのかは不明です。

答えて

0

問題の大部分は、DRIVERプログラムが予期していたよりもはるかに多くのRAMを必要としていたようです。

ドライバー・プログラムは、あらゆるcollecttakegroupByなどを行っているだけcount年代されていません。なぜcountがドライバーに重要なリソースを必要とするのか分かりません。ドライバの詳細を絞り込む際に、ここで詳細を追加します。

関連する問題