JobTracker节点后台线程之RetireJobs

     Hadoop中的用户作业在其整个生命周期中有5个状态,它们分别是:PREP、RUNNING、SUCCEEDED、FAILED、KILLED,而这其中的SUCCEEDED、FAILED、KILLED三个状态是互斥的,都可看做是Job的完成状态。当用户成功的提交了一个Job之后,这个Job就会进入PREP状态,然后这个Job的map启动任务会被首先交给一个TaskTracker节点来完成,当这个任务被成功执行之后,Job就会进入RUNNING状态,最后随着Job的map任务和reduce任务的完成状态,Job进入FAILEDSUCCEEDEDKILLED中的某一个状态,这个状态图如下:


    当一个作业处于完成状态之后,JobTracker节点的任务调度器就不需要再考虑该Job了,也就是JobTracker需要把该Job从作业队列中删除。但是,JobTracker节点并不是马上就把与这个Job相关的信息删除掉,而是先把它缓存起来,同时建立一个用户与Job的映射,这个用户是指提交该作业的用户。至于JobTracker为什么会这么做,笔者目前也没有完全弄明白,推测可能与用户作业历史记录有关,也或者和集群的负载统计有关(如果有朋友知道这其中的原因可以@我)。当然这里可能有一个问题就是,JobTracker节点是否一直会缓存这些已完成Job的信息呢?实际上是不会的,因为JobTracker节点为每一个缓存的已完成Job信息设置了一个生命周期,当过了这个生命周期,这个缓存信息就会被清除掉。这个清理工作被设计成了JobTracker节点的一个组件——RetireJobs,这个RetireJobs作为JobTracker节点的后台线程,会定时的检测每一个缓存的已完成Job信息的生存时间是够已过期,如果过期了,他就会被清除。这个检查的间隔时间为RETIRE_JOB_CHECK_INTERVAL ms,默认值是60000,但也可通过配置文件来设置,对应的配置项为:mapred.jobtracker.retirejob.check。而每一个已完成Job信息的生存时间为RETIRE_JOB_INTERVAL ms,它的默认值24*60*60*1000,当然也可以通过配置文件来设置,对应的配置项为:mapred.jobtracker.retirejob.interval。这个过程的具体源码如下:

static final int MIN_TIME_BEFORE_RETIRE = 60000;

public void run() {
    while (true) {
      try {
        Thread.sleep(RETIRE_JOB_CHECK_INTERVAL);
        List<JobInProgress> retiredJobs = new ArrayList<JobInProgress>();
        long now = System.currentTimeMillis();
        long retireBefore = now - RETIRE_JOB_INTERVAL;

        synchronized (jobs) {
          for(JobInProgress job: jobs.values()) {
            if (job.getStatus().getRunState() != JobStatus.RUNNING &&
                job.getStatus().getRunState() != JobStatus.PREP &&
                (job.getFinishTime() + MIN_TIME_BEFORE_RETIRE < now) &&
                (job.getFinishTime()  < retireBefore)) {
              retiredJobs.add(job);
            }
          }
        }
        
        if (!retiredJobs.isEmpty()) {
          synchronized (JobTracker.this) {
            synchronized (jobs) {
              synchronized (taskScheduler) {
                for (JobInProgress job: retiredJobs) {
                  removeJobTasks(job);
                  jobs.remove(job.getProfile().getJobID());
                  for (JobInProgressListener l : jobInProgressListeners) {
                    l.jobRemoved(job);
                  }
                  String jobUser = job.getProfile().getUser();
                  synchronized (userToJobsMap) {
                    ArrayList<JobInProgress> userJobs =  userToJobsMap.get(jobUser);
                    synchronized (userJobs) {
                      userJobs.remove(job);
                    }
                    if (userJobs.isEmpty()) {
                      userToJobsMap.remove(jobUser);
                    }
                  }
                  LOG.info("Retired job with id: '" + job.getProfile().getJobID() + "' of user '" + jobUser + "'");

                  // clean up job files from the local disk
                  JobHistory.JobInfo.cleanupJob(job.getProfile().getJobID());
                }
              }
            }
          }
        }
      } catch (InterruptedException t) {
        break;
      } catch (Throwable t) {
        LOG.error("Error in retiring job:\n" + StringUtils.stringifyException(t));
      }
    }
    
    LOG.debug("Job Retire Thread is to stop..");
}

     但是,JobTracker节点的资源是有限的,如果某一个用户频繁的提交Job,那么这个用户对应的已完成Job信息缓存会占用大量的系统资源,所以JobTracker节点又设计了另一个检测机制,就是当一个作业完成时,它会判断这个Job对应的提交用户缓存的已完成Job信息的数量有没有达到一个阈值MAX_COMPLETE_USER_JOBS_IN_MEMORY,如果达到了这个阈值的话,就会删除他的所有缓存时间超过 MIN_TIME_BEFORE_RETIRE ms的已完成Job信息,直到这个用户缓存的已完成Job信息的数量下降到这个阈值。MAX_COMPLETE_USER_JOBS_IN_MEMORY可以通过配置文件来配置,对应的配置项为:mapred.jobtracker.completeuserjobs.maxinum,但它的默认值是100。





评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值