OOM
# 包括GC Overhead limit
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
以上皆为可能的报错（但不代表报错一定就是OOM相关，要去找cause的exception；OOM不过是其中一种可能的cause），大致原因是shuffle后的executor读取数据超出了内存限制，然后挂了并且清除了相关的中间临时文件，其他的executor在尝试与其进行数据沟通时，要么executor丢失，要么无法读取其写出的shuffle文件等。当然FetchFailedException还有可能是其他原因，譬如某台机太繁忙无法响应等，这种情况可以尝试调整相关timeout参数进行尝试： spark.shuffle.io.maxRetries=6 ，spark.files.fetchTimeout=120s 。
如果你的单个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部分参数说明 - 有可能也是你物理内存不够了，增加可用内存吧
- 优化数据结构使用，尽量使用原始类型和数组，泛型和对象会造成较大的传输和存储开销。可考虑利用一些高效的序列化方案，比如protostuff。
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
其实以上的很多解决办法基本是OOM大多数问题通用的，比如持久化、内存调大、数据结构优化。
如果以上问题还不能解决，请参考：http://spark.apache.org/docs/latest/tuning.html 中的 Memory Tuning部分