Spark 1.x 爆内存相关问题汇总及解
Posted Lhfcws
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Spark 1.x 爆内存相关问题汇总及解相关的知识,希望对你有一定的参考价值。
OOM
java.lang.OutOfMemoryError # on yarn org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl - Container [<edited>] is running beyond physical memory limits. Current usage: 18.0 GB of 18 GB physical memory used; 19.4 GB of 37.8 GB virtual memory used. Killing container. Container exit code: 137 Task process exit with nonzero status of 137.
除了 exit code 137
外其它OOM提示都很明显,yarn container 137退出码按照SO的大神说:“Exit code 137 is a typical sign of the infamous OOM killer.”
解决方法:
- 加 executor 内存(spark.executor.memory),需注意on yarn时进程是按最小container memory的整数倍分配的。
- 优化程序内存占用
- 设置StorageLevel 到 DISK 或 MEMORY AND DISK,要注意persist只在action执行才生效,所以建议先count或isEmpty一下触发persist,然后再去做自己的flatMap/foreach等业务操作
Ref: hadoop-streaming-job-failure-task-process-exit-with-nonzero-status-of-137
Shuffle Read OOM
org.apache.spark.shuffle.MetadataFetchFailedException: Missing an output location for shuffle 0 org.apache.spark.shuffle.FetchFailedException: Failed to connect to ip-xxxxxxxx org.apache.spark.shuffle.FetchFailedException: Error in opening FileSegmentManagedBuffer java.io.FileNotFoundException of shuffle files in HDFS/S3 # if open wal org.apache.spark.SparkException: Could not read data from write ahead log record FileBasedWriteAheadLogSegment
以上皆为可能的报错,大致原因是shuffle后的executor读取数据超出了内存限制,然后挂了并且清除了相关的中间临时文件,其他的executor在尝试与其进行数据沟通时,要么executor丢失,要么无法读取其写出的shuffle文件等。
如果你的单个shuffle block超过2g,然后又报类似以上列举的错误,你可能遭遇了以下 issue :
解决办法:
- 调大 repartition 数,减少每个repartition的size
- 调大executor内存
- on yarn的需调大 spark.executor.overheadMemory,按SO的说法,需要自己根据实际情况测试调到不报错为止。。
- 根据实际情况调整 spark.shuffle 的相关参数。shuffle参数中大多数是关于shuffle write和shuflling的配置,而且基本大多数默认都是比较优的配置了。唯一shuffle read相关的
spark.reducer.maxMbInFlight
涉及源码参见 Spark技术内幕: Shuffle详解(二) ,因为shuffle fetch阶段是边fetch边处理的,所以适当调小该值有助于改善shuffle阶段的内存占用。 shuffle部分参数说明
Ref:
what-are-the-likely-causes-of-org-apache-spark-shuffle-metadatafetchfailedexcept
fetchfailedexception-or-metadatafetchfailedexception-when-processing-big-data-set
Streaming OOM
java.lang.Exception: Could not compute split, block input-0-1412705397200 not found
Spark Streaming 中此错误产生原因是streaming产生了堆积,超过了receiver可承受的内存大小,因此旧的未执行的job被删除来去接收新的job。
解决方法:
- 调大 receiver 内存
- kafka 直接消费没有做rdd transform的可考虑换 direct stream ,防止堆积。
- spark 1.6.x 可采用 spark.streaming.backpressure.enabled 机制回压,控制接收速率,防止爆内存。SparkConf设置
spark.streaming.backpressure.enabled=true
,spark.streaming.backpressure.pid.minrate=0.001
Ref:
Insufficient Physical Memory
There is insufficient memory for the Java Runtime Environment to continue. Native memory allocation (malloc) failed to allocate 4088 bytes for AllocateHeap An error report file with more information is saved as:
其实就是没有足够的物理内存去启动这个JVM了,比如你JVM申请5g,实际只剩下4g可用的物理内存,就会报错,然后jvm启动失败进程退出。
解决方法:
- 加物理内存
- 优化程序,调低jvm内存需求
- kill掉其他占用系统内存进程释放可用内存
问题:这里的可用内存包不包括操作系统cache的内存呢? (free -m
可查看OS的free和cached内存)
Ref : insufficient-memory-for-the-java-runtime-environment-message-in-eclipse
以上是关于Spark 1.x 爆内存相关问题汇总及解的主要内容,如果未能解决你的问题,请参考以下文章
spark关于join后有重复列的问题(org.apache.spark.sql.AnalysisException: Reference '*' is ambiguous)(代码片段