• MapReduce作业的map task和reduce task调度参数


    MapReduce作业可以细分为map task和reduce task,而MRAppMaster又将map task和reduce task分为四种状态:

      1、pending:刚启动但尚未向resourcemanager发送资源请求;

      2、scheduled:已经向resourceManager发送资源请求,但尚未分配到资源;

      3、assigned:已经分配到了资源且正在运行;

      4、completed:已经运行完成。

      map task的生命周期为:scheduled -> assigned -> completed
      reduce task 生命周期:pending -> scheduled -> assigned -> completed。

      由于reduce task的执行需要依赖于map task的输出结果,因此,为避免reduce task过早启动造成资源利用率底下,MRAppMaster让刚启动的reduce处于pending状态,以便能够根据map task的运行情况决定是否对其进行调度。

      那么如何确定reduce task启动时机呢?因为YARN没有Hadoop 1.x里面的map slot和reduce slot概念,且ResourceManager也不知道map task和reduce task之间的依赖关系,因此MRAppMaster自己需要设计资源申请策略以防止因reduce task过早启动照成资源利用率低下和map task因分配不到资源而饿死。MRAppMaster在MRv1原有策略(map task完成数目达到一定比例后才允许启动reduce task)基础上添加了更为严格的资源控制策略和抢占策略,这里主要涉及到以下三个参数:

      mapreduce.job.reduce.slowstart.completedmaps:其英文含义是:Fraction of the number of maps in the job which should be complete before reduces are scheduled for the job。当map task完成的比例达到该值后才会为reduce task申请资源,默认是0.05。

      yarn.app.mapreduce.am.job.reduce.rampup.limit:在map task完成之前,最多启动reduce task比例,默认是0.5

      yarn.app.mapreduce.am.job.reduce.preemption.limit:当map task需要资源但暂时无法获取资源(比如reduce task运行过程中,部分map task因结果丢失需重算)时,为了保证至少一个map task可以得到资源,最多可以抢占reduce task比例,默认是0.5

      如果上面三个参数设置的不合理可能会出现提交的job出现大量的reduce被kill掉,这个问题其实是reduce 任务启动时机的问题,由于yarn中没有map slot和reduce slot的概念,且ResourceManager也不知道map task和reduce task之间的依赖关系,因此MRAppMaster自己需要设计资源申请策略以防止因reduce task过早启动照成资源利用率低下和map task因分配不到资源而饿死,然后通过抢占机制,大量reduce任务被kill掉。可以合理调节上面三个配置参数来消除这种情况。


  • 相关阅读:
    2016年之前优秀的单目SLAM系统
    EPSON四轴机械臂原点校准
    运动控制之手眼定位
    【已解决】移动端页面手势滑动触发touch 事件时,在左右上下部分出现空白部分的问题
    es分组排序和聚合后再筛选
    git配置ssh和小乌龟配置ssh
    单调栈的简单分享 Marathon
    es6.18升级到es7.17的不同点记录 Marathon
    input的ref属性
    手写axios
  • 原文地址:https://www.cnblogs.com/itboys/p/5769057.html
Copyright © 2020-2023  润新知