标签： sparkIMF
##一：Shuffle性能调优
- 问题：Shuffle output file lost？ 真正的原因是GC导致的！！！如果GC尤其是Full GC产生通常会导致线程停止工作，这个时候下一个Stage的Task在默认情况下就会尝试重试来获取数据，一般重试3次，每次重试的时间为5s，也就是说15秒内如果还是无法抓到数据的话，就会出现Shuffle output file lost等情况，进而会导致Task重试，甚至会导致Stage重试，最严重的是会导致Application失败！在这个时候首先就要采用高效的内存数据结构和序列化机制、JVM的调优来减少Full GC的产生。
- 在Shuffle的时候，Reducer端获取数据会有一个指定大小的缓存空间，如果内存足够大的情况下，可以适当的增大该缓存空间，否则会spill到磁盘上，影响效率。 此时可以调整（增大）spark.reducer.maxSizeInFlight（一个Task占用的缓存大小）参数，默认48MB
- 在ShuffleMapTask端通常也会增大Map任务的写磁盘的缓存，默认情况下是32KB，spark.shuffle.file.buffer 32k。
- 调整获取Shuffle数据的重试次数，默认是3次，通常建议增大重试次数；调整获取Shuffle数据重试的时间间隔，默认5s，强烈建议提高该时间，spark.shuffle.io.retryWait 5s
- 在reducer端做Aggregation的时候，默认是20%的内存用来做Aggregation，如果超出了这个大小就会溢出到磁盘上，建议调大百分比来提高性能：spark.shuffle.memoryFraction 0.2。
IMF人员补充：如果spark.shuffle.split为true，shuffle中聚合和合并组操作使用的Java堆内存占总内存的比重。在任何时候，shuffles使用的所有内存内maps的集合大小都受这个限制的约束。超过这个限制，spilling的数据将会保存到磁盘上，如果spilling太过频繁，考虑增大这个值
##看你是不是高手？看你不做什么，而不是什么都做！