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 ： 

• SPARK-5928 Remote Shuffle Blocks cannot be more than 2 GB 
  
  
• SPARK-1476 2GB limit in spark for blocks

解决办法：

• 调大 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: 

• Spark Streaming : Could not compute split, block not found

• could-not-compute-split-block-not-found

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内存）