JVM调优：
Executor JVM堆内存 分为三块 静态资源划分
(60%（RDD以及广播变量存储的位置）+20%（运行内存）+20%（reduce 聚合内存）)*90%+10%（JVM自身预留） = JVM堆内存
JVM的gc回收流程(属于运行内存中)：
在task中创建出来的对象首先往eden和survior1种存放，survior2是空闲的。当eden和survior1区域放满以后就会触发minor gc(小型垃圾回收)，清理掉不再使用的对象(死亡)。
会将存活下来的对象放入survior2中，如果存活下来的对象大于survior2的大小，那么JVM就会通过担保机制将多余的对象直接放入到老年代中。
如果这个时候年轻代的内存不是很大的话就会经常的进行minor gc(小型垃圾回收)，频繁的minor gc会导致这段时间内有些存活的对象(多次垃圾回收都没有回收掉，一直在用又不能被释放)频繁的倒来倒去，会导致这些短生命周期的对象(不一定长期使用)每进行一次垃圾回收就会长一岁，年龄过大默认15岁，垃圾回收还是没有回收回去的就会跑到老年代里面去。
就会导致老年代中存放大量的短生命周期的对象，老年代应该存放的是数量比较少并且长期使用的对象，比如数据库连接池。这样的话，老年代就会溢满，触发full gc，因为本来老年代中的对象很少，很少进行full gc因此采取了不太复杂但消耗性能和时间的垃圾回收算法。
不管minor gc还是full gc都会导致JVM的工作线程停止
总结：堆内内存不足造成的影响
1，频繁的minor gc
2，老年代大量的短生命周期的对象会导致full gc
3，有了gc 就会影响Spark的性能和运行速度
增加内存或者提高运行内存比例解决频繁gc
还有一种方案：
统一的内存管理：JVM堆内存-300M
运行内存 占剩余内存的50%
存储内存 占剩余内存的50%
运行内存和存储内存可互相借用
Shuffle的调优
1、buffer的大小 32k
2、reduce task拉数据 3s 5次
3、hashShuffle 合并机制
4、每次拉取的数据量
5、reduce 聚合的内存比例
6、bypass 机制
7、spark.shuffle.manager sort 选用哪种shuffle
shuffle file connot find（磁盘小文件找不到的原因）？
Executor挂掉：
堆内内不足 --executor-memory 10G
堆外内存不足 shuffle有数据传输，netty 内部封装的是java NIO，是零拷贝，拷贝到堆外内存中
默认是这个Executor内存的10%
2G * 10% = 200M
如何调整堆外内存？
yarn：
--conf spark.yarn.executor.memoryOverhead=2048
standalone：
--conf spark.executor.memoryOverhead=2048
注意事项：
spark-submit脚本里面，去用--conf的方式，去添加配置
Executor没有挂掉：
建立通信失败：
如何提高建立通信的等待时间
--conf spark.core.connection.ack.wait.timeout=60s
注意事项：
spark-submit脚本里面，去用--conf的方式，去添加配置
数据传输的过程
暂时不知道
reduce oom问题
1，map端的map task计算完成后会将task计算的结果根据分区器的策略写入到磁盘小文件中
2，reduce端聚合的时候，会产生5个拉取数据的子线程，每次总共拉取48M的数据，reduce task来执行计算这些数据，默认reduce task端占20%的执行内存，当执行速度小于拉取速度时就会产生reduce oom
解决办法：
1，每次拉取数据从48M减少至24M
2，增加worker中的内存或者聚合比例 spark.shuffle.memoryFraction