之前有一段时间。我们的hadoop2.4集群压力非常大。导致提交的job出现大量的reduce被kill掉。同样的job执行时间比在hadoop0.20.203上面长了非常多。这个问题事实上是reduce 任务启动时机的问题，因为yarn中没有map
slot和reduce slot的概念，且ResourceManager也不知道map task和reduce task之间的依赖关系，因此MRAppMaster自己须要设计资源申请策略以防止因reduce task过早启动照成资源利用率低下和map task因分配不到资源而饿死，然后通过抢占机制。大量reduce任务被kill掉。

MRAppMaster在MRv1原有策略（map task完毕数目达到一定比例后才同意启动reduce task）基础上加入了更为严格的资源控制策略和抢占策略：

1、mapreduce.job.reduce.slowstart.completedmaps

当map 任务完毕的比例达到该值后才会为reduce task申请资源，默认是0.05。

我们设置为0.5，也即map完毕了50%之后在開始为reduce任务申请资源。

2、yarn.app.mapreduce.am.job.reduce.rampup.limit

在map任务完毕之前，最多启动reduce 任务比例，默认是0.5

我们设置为0.2。也即map任务所有完毕前，最多去启动20%的reduce任务。

3、yarn.app.mapreduce.am.job.reduce.preemption.limit

当map task须要资源但临时无法获取资源（比方reduce task执行过程中。部分map task因结果丢失需重算）时，为了保证至少一个map task能够得到资源。最多能够抢占reduce task比例，默认是0.5。

我们用的时默认值。

我们集群通过改动了第一个和第二个參数的默认值，在也没用出现大量reduce被kill的情况了。

參考：http://blog.csdn.net/jiushuai/article/details/17733581