Spark JVM的OOM和Stack Overflow问题
1、Spark on Yarn下JVM的OOM问题及解决方式
2、Spark中Driver的Stack Overflow的问题及解决方式
Spark on Yarn cluster mode: 此时有可能会报OOM的错误，具体来说：
由于Client模式下一定没有出现OOM，而在Cluster模式下一定出现了OOM，所以必然说明OOM是Driver导致的！
Driver在Client和Cluster模式下占用的内存都是一致的，例如都是100M，现在的问题是为什么在Client下的100M不会OOM，但是在Cluster模式下的100M会出现OOM？
更进一步：这个OOM是永久代产生的OOM
真相是：无论在Client模式还是在Cluster模式下，我们的Driver都是运行在JVM中的，而JVM一定有具体的例如永久代的配置参数等信息。在Client模式下，加载本地的配置信息的时候，Driver所在的JVM的永久代的默认大小是128MB，而在Cluster下默认的永久代的大小是82MB，当你的代码业务逻辑很多的时候，就要构造很多永久代的对象，此时的永久代消耗的大小例如说是100MB，所以在Client模式下可以成功运行，但是在Cluster模式下因为100M大于82M，所以就产生永久代的OOM问题，导致程序启动失败！
解决方式：
在spark-submit的时候设定conf部分的 spark.driver.extraJavaOptions: -XX:PermSize=256M -MaxPermSize-256M，现实生产环境下大多数都是使用Java7，Java8设置元数据空间。
Spark运行时候的StackOverflow问题：
之所以产生Stack Overflow，原因是在Stack方法栈中方法的调用链条太长所导致的，经典的过长链条有两种：
第一种：过于深度的递归
第二种：过于复杂的业务调用链条（很少见！）
在Spark中什么时候会出现Stack Overflow呢？
例如SQL语句中的条件组合太多，而SQL在Spark SQL中会通过Catalyst首先变成一棵树，并最终变成RDD的编程实现。在这个过程中，有可能把我们的SQL语句解析成为不断地递归调用，此时就有可能出现Stack Overflow的情况。什么样的SQL语句？例如：SELECT … FROM … WHERE ..OR…OR…OR…OR…
怎么办？
对于SQL的情况就要进行拆分！例如把一个很长的SQL语句变成很多小的SQL语句，构成很多子查询。
1、Reduce端的OOM如何解决？
2、Shuffle file not found如何解决？
OOM产生的原因：数据对象太多。通过减少减小Cache层大小，从而减少OOM
代价：从Mapper端拉去数据的次数增多，性能下降
如果发生Reducer端的OOM，可以减少每个Reduce Task的缓存的大小，例如从默认的48MB降低到24MB，这样让程序可以从OOM崩溃的状态到可以运行的状态；
一个额外的调优技巧：如果内存足够大，可以增加缓存的大小，例如从48MB提升到96MB，这样可以减少网络传输的次数从而提高性能。
参数是：spark.reducer.maxSizeInFlight
一般情况下当Executor进行GC的时候，所有的线程都停止工作，当然包括进行数据传输的Netty中的线程也会停止工作，所以就暂时无法获取数据。
当Reducer端根据Driver端提供的信息到Mapper中指定的位置去获取属于自己的数据的时候，首先会去定位数据所在的文件，而此时可能发生shuffle file not found的错误。这个错误的出现一般是由于Mapper端正在进行GC，然后我们去请求数据的时候没有相应，spark.shuffle.io.maxRetries = 3 spark.shuffle.io.retryWait = 5s，默认情况下15s还没有拉到属于自己的数据就会出现shuffle file not found的错误。
解决办法是调大上述参数，建议调成spark.shuffle.io.maxRetries = 30，spark.shuffle.io.retryWait = 30s