mapreduce作业reduce被大量kill掉

       之前有一段时间。我们的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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值