spark troubleshooting之解决JVM GC导致的shuffle文件拉取失败

在shuffle中，我们map端的task向磁盘文件写入数据，其实是task所在的executor上分配一个BlockManager的，这个BlockManager管理这些磁盘数据，task会向BlockManager中写一份数据，然后将数据的元信息提交到Driver中一份，这时，reduce端想要拉取数据，就会想Driver申请，然后告诉Driver自己想拉取的那份数据，但是它记录的是元数据，需要从那个Executor的BlockManager中拉取，如果此时这个Executor进程在GC,那么这个进程就会停止，这个时候，我们的系统就会出错，shuffle file not found(spark 作业中，这个是非常常见的)

有时候出现这种情况，重新提交一次就好了，这个时候很有可能就是map端executor进程的JVM内存不是很够用了，那么此时可能就会执行gc可能是minor gc，也可能是full gc，总之，一旦发生了JVM gc 以后，就会导致executor内，所有的工作线程就会全部停止，但是下一个stage的executor，可能还没有停止掉的，task想要去上一个stage的task所在的executor,去拉取属于自己的数据，由于对方正在gc,所以半天没有拉取到，就会报错

 

这里该怎么解决？

spark.shuffle.io.maxRetries 3 

shuffle文件拉取的时候如果没有拉取到，最多会重试几次（会重新拉取几次，默认是拉取三次）

spark.shuffle.io.retryWait 5s

每次重试拉取文件的时间间隔默认是5s中

默认情况下，假如说，第一个stage的executor正在进行漫长的full gc，第二个stage的executor尝试去拉取文件，结果没有拉取到，默认情况下，会反复重试拉取3次，每次间隔是五秒，最多只会等待3*5s = 15s，如果15s内，没有拉渠道shuffle file,就会报出shuffle file not found。

针对这种情况，完全可以增大上边俩个参数的值，尽量保证第二个stage的task可以拉取到

spark.shuffle.io.maxRetries 60 

spark.shuffle.io.retryWait 60s