磁盘空间不足导致task的mapred local文件无法写入而失败解决

Task 在运行的过程中，是需要写本地文件 系 统 的，hadoop中就有配置选项 mapred .local.dir 来配置这个本地文件的写入点，可以有多个写入点，通常如果每个slave上有多个磁 盘 ，分别挂载在 /disk{1..3}  的话，就可以将之配置为：

<property>
  <name>mapred.local.dir</name>
  <value>/disk1/mapred/local,/disk2/mapred/local,/disk3/mapred/local</value>
</property>

这 样多个 task在同一个TT上运行的时候，就可以分别写不同的磁盘写入点，以增大作业运行的磁盘吞吐率。

但是这里面有一个问题，如果某 个 task 被assign 到了一个TT上，这个task 在运行中需要写向某个写入点的本地文件系统中写job的intermediate中间文件，但是发现这个写入点所在的磁盘，空间 不够，这就会导致这个task 运行失败。此时TT会在下一次heartbeat的时候向 JT 报告这个情况， JT 接到这个信息以后，会将这个task重新 进行assign，到有slots空闲的TT上去，但是这个时候，仍然有可能会重新 assign到这个出错的TT上，极端的情况下， 这个新的task又会写同一个local 写入点，然后有再次失败。这 样的情况，就会致使 同一个task被多次的执行，会影响job的效率，严重的时候，甚至会因为同一个task多次的失败（默认4次）而导致整个job失败！即使没有导致整个 job失败，但是有时候有些 reduce task需要运行很久才完成，比如一个小时，如果运行到59分钟的时候出现这种情况，即使下一次的重新执行能够成功，这个job也因为这个reduce的 原因而延迟结束了将近一个小时，这也是非常大的代价。

       归根结底，这样的情况，都是因为在task 在TT上被launch之前，没有事先判断该task的运行过程中需要写入的本地local 文件系统是否有足够的空闲空间来支持这个task正确跑完，如果能够在task 被launch之前进行判断，一旦某个写入点的磁盘剩余不够某个值（可配置），就不让这个task被运行。或者在task运行过程中 某个写入点的剩余值不够某个值了（可配置），那么就主动的将这个task kill掉，以尽快的重新执行，那么就能提高job的运行效率，减少出错。

       之前对于这种问题，由于我们的集群是将mapred.local.dir以及dfs.data.dir配在了同一个磁盘上，在之前的一篇中我们的策略是对 dfs.datanode.du.reserved的配置选项进行加大，这样就可以让dfs留出一定量的空间，供mapred的local来使用，并解决 了 dfs.datanode.du.reserved的一个bug。但是这并不是直接的解决这个问题。


      其实，hadoop的TaskTracker中对这样的情况是有考虑的，有两个配置选项：

• mapred.local.dir.minspacestart ： 这个选项用来告诉tasktracker，当某个mapred local 写入点的磁盘剩余空间小于这个配置的值的时候，该 TT就不再接受新的task。
• mapred.local.dir.minspacekill ： 这个选项用来告诉tasktracker，当某个mapred local写入点的剩余磁盘空间在task的运行过程中小于这个值的时候，该TT就不再接受新的task分配，直到已经在其上面运行的task都完成。并 且，为了让正在运行的 task 能够顺利运行完成，将这些task中的某一个kill掉，以释放它占用的磁盘空间。kill的策略是，先从reduce开始，然后kill掉完成百分比最 小的一个。

所以，要解决以上的问题，就比较简单了，在hadoop-site.xml 中对这两个值进行配置，并重启 TT，就可以避免以上问题：
<property>
  <name>mapred.local.dir.minspacestart</name>
  <value>×××</value>
</property>

<property>
  <name>mapred.local.dir.minspacekill</name>
  <value>×××</value>
</property>


之前发生以上的提到 的情况，其实就是因为，这两个值的默认为0，导致除非磁盘被完全写满，否则 task 就会一直认为可运行，并写数据 ，直到无法再写的时候失败。

Ref: http://blog.csdn.net/ae86_fc/article/details/5284273