磁盘空间不足导致task的mapred&nbs…

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

mapred.local.dir


/disk1/mapred/local,/disk2/mapred/local,/disk3/mapred/local

这 样多个 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，就可以避免以上问题：

mapred.local.dir.minspacestart

×××

mapred.local.dir.minspacekill

×××

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