• 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掉。可以合理调节上面三个配置参数来消除这种情况。


  • 相关阅读:
    Docker安装Zookeeper并进行操作
    JVM 完整深入解析
    synchronized关键字加到static静态方法和非static静态方法区别
    submit与execute区别
    ThreadPoolTaskExecutor和ThreadPoolExecutor区别
    Redis占用内存大小
    Java中CycliBarriar和CountdownLatch区别
    Java并发编程:线程间协作的两种方式:wait、notify、notifyAll和Condition
    文本格式
    JavaScript事件
  • 原文地址:https://www.cnblogs.com/itboys/p/5769057.html
Copyright © 2020-2023  润新知