堆内和堆外内存规划
Spark中未进行序列化的对象，由于其占用的内存是通过周期性地采样近似估算而得，即并不是每次新增的数据项都会计算一次占用的内存大小，所以可能导致Spark标记为释放的内存但是JVM并没有释放导致实际可用的内存小于Spark记录的可用内存，甚至OOM
堆外内存直接向操作系统申请，所以可以实现精准的空间计算
1、Executor堆内、堆外内存配置
在spark3.x中，可以通过metrics中的peak JVMHeapMemory、peak JVMOffHeapMemory来确定executor需要的峰值内存；在spark2.x版本可以通过配置spark.metrics.conf上报JvmSource至第三方存储，从而进一步分析executor内存信息。(在on yarn的情况下，可以通过NodaManager日志来查看container的physical memory占用记录，该方法会有一定误差，也无法准确判定堆外、堆内的实际占用，可以作为参考数据。)
2、堆外内存
在上面的分析中，我们知道：执行内存只能全是堆内内存或全是堆外内存，存储内存可以通过指定StorageLevel指定使用off_heap内存。一般不建议开启spark.memory.offHeap.enabled来使用堆外内存。虽然堆外内存可以减少不必要的GC开销，但是实际测试中，运行效率没有明显的提升；另外，开启之后，执行内存只能使用堆外内存，对于堆内内存来说，可能造成不必要的浪费。
3、SparkOutOfMemoryError
SparkOutOfMemoryError一般是task无法分配更多内存导致。一般可以通过增加spark.executor.memory大小解决；也可以通过减少并行task数spark.executor.cores，或者增加spark.default.parallism或spark.sql.shuffle.partition，减少每个task处理的数据量解决。
4、GC overhead limit exceeded
可以参考官方的GC调优：http://spark.apache.org/docs/latest/tuning.html#garbage-collection-tuning
5、Container killed by YARN, consider boosting spark.yarn.executor.memoryOverhead
on yarn模式下，实际内存占用超过申请内存上限会被yarn kill掉。该错误跟oom的区别主要在于：oom主要是内存占用超过Heap上限或者无法申请到更多执行内存、存储内存而导致。一般可以通过增加spark.yarn.executor.memoryOverhead解决。
6、执行内存、存储内存配置问题
在上面的分析中，我们知道统一内存 = 执行内存 + 存储内存，相应的如果能跟jvm一样确定执行内存和存储内存的峰值占用，则可以根据峰值信息优化统一内存配置。在spark3.x中，ExecutorMetrics提供如下metrics信息，可以帮助我们分析统一内存的实际使用，进而通过spark.memory.fraction、spark.memory.storageFraction调整执行内存、存储内存的大小。
|
|