報錯java.lang.OutOfMemoryError: GC overhead limit exceeded

HDFS上有一些每天增長的文件，使用Snappy壓縮，突然某天OOM了

1.原因:

因為snappy不能split切片，也就會導致一個文件將會由一個task來讀取，讀取后解壓，數據又會膨脹好多倍，如果文件數太大而且你的并行度也挺大，就會導致大量full gc，最終OOM

為了程序能快速跑起來，只好將最后入HDFS前reparation(500),修改為1000，增加文件數，減少每個文件數據量。

我自己的理解是如果HDFS上的Snappy壓縮文件需要Spark等計算框架取讀取并且需要切片，那么就要手動將文件大小控制在128MB附近，以使計算效率最大化，但是解壓后的數據仍然翻大約3倍

---

---

---

下面記錄一下，找問題，修復問題的過程，以及Spark參數調優的過程，很漫長，太菜了。

HDFS上的文件

可以看到一個文件快700MB了，一共500個文件。
當使用Spark讀取后做一系列計算就開始報錯OOM，用Jstat -gc pid 1000 查看gc情況，發現當執行到stage1的textFile讀取文件時就會卡住然后一直進行full GC，最終OOM。

1.以為是數據傾斜，因為總是某個stage某個task執行時卡住

對數據進行抽樣查看，發現并沒有數據傾斜，基本上沒有重復數據

rdd.sample(0.1,false).countByKey().forEach((k,v) ->System.out.println(k+"---"+v));

2.可能內存不夠用，或者參數調整的不對，開始調參

**方向：1.加內存、2.堆外內存、3.調JVM參數、4.調整緩存和執行參數比例、5.增加核數增加并行度，減少每個task處理的數據量、6、調整代碼增加shuffer時的分區數、6.調整代碼先聚和之類的

因為代碼比較多，劃分的stage比較多，一時間通過WEB UI沒看出來是當前stage中哪個算子出現的問題，一直以為是reduceBykey的時候報的錯，導致方向找錯了，所以怎么調整都是錯的
收獲就是對調參的了解更熟練了。

1.一開始就以為是執行內存不足所以我將fraction調為0.8，storageFraction調為0.2，不斷的增大執行內存，都無濟于事。

--conf spark.memory.fraction=0.8 --conf spark.memory.storageFraction=0.3

2.調整代碼提前過濾數據之類的全部嘗試了，沒用。

3.期間我修改了讀取文件時的分區數竟然沒想到是切片問題，發現不管怎么調整都只有500，當時還在疑惑為啥啊，┭┮﹏┭┮

3.后來看WEB UI中task執行情況，其實卡住的task一直在讀取數據，input Size 項是在不斷增加的，下面是后來我修改后讀取的大小，一直讀到700MB，過程很慢，而且如果core數大也就是并行度大的話，我這里320個task并行度，每一個要讀取700MB，并且是需要解壓的，Snappy解壓后3G左右，查看task的errlog會發現日志出現具體我記不清了，大概就是讀取xxxx文件3G，通過內存spill到了磁盤多少多少之類的，看到一個task讀了這么大，才忽然想起來snappy是不能split切片的

就會導致一個文件使用一個task讀取全部數據并解壓，最終OOM

也可能我當時參數調整的不好，后面學習并總結了一下內存調參，詳見：

https://blog.csdn.net/weixin_43736084/article/details/121541393

參數調整：

# --為了好看換行了 spark-submit --master spark://11.172.54.167:7077 --class $main --deploy-mode client --driver-memory 16g --executor-memory 25g --executor-cores 8 --total-executor-cores 320 --conf spark.memory.fraction=0.8 --conf spark.memory.storageFraction=0.3 --conf spark.memory.offHeap.enabled=true --conf spark.memory.offHeap.size=5g --conf "spark.executor.extraJavaOptions=-XX:+UseG1GC -XX:-TieredCompilation -XX:G1HeapRegionSize=16m -XX:InitiatingHeapOccupancyPercent=55 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:-UseCompressedClassPointers -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m -XX:ReservedCodeCacheSize=512m -XX:+UseCodeCacheFlushing -XX:ParallelGCThreads=20 -XX:ConcGCThreads=20 -Xms20g -XX:+PrintGCDetails -XX:+PrintGCTimeStamps" --jars $jars xxxx.jar $date1 $max $date2 >> log/$log_file#代碼內參數 conf.set("spark.driver.maxResultSize", "8g"); conf.set("spark.serialize", "org.apache.spark.serializer.KryoSerializer"); conf.registerKryoClasses(new Class[]{ImmutableBytesWritable.class, HyperLogLog.class, HashSet.class, RegisterSet.class, IllegalArgumentException.class, FileCommitProtocol.TaskCommitMessage.class}); //conf.set("spark.kryo.registrationRequired","true"); #開啟的話類沒加到上面會報錯 conf.set("spark.kryoserializer.buffer.mb", "10"); conf.set("spark.shuffle.file.buffer", "128"); conf.set("spark.reducer.maxSizeInFlight", "144"); conf.set("spark.shuffle.io.maxRetries", "50"); conf.set("spark.shuffle.io.retryWait", "5s");

總結

以上是生活随笔為你收集整理的Spark读取HDFS上的Snappy压缩文件所导致的内存溢出问题 java.lang.OutOfMemoryError: GC overhead limit exceeded的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。