hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vivek Ratan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-4768) Dynamic Priority Scheduler that allows queue shares to be controlled dynamically by a currency
Date Wed, 10 Dec 2008 08:58:44 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-4768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655143#action_12655143

Vivek Ratan commented on HADOOP-4768:

Agree with Matei. Thomas, you really should be creating your own separate scheduler, rather
than building a meta-scheduler, for various reasons: 
* Schedulers interact with the JT through the _TaskScheduler_ class. This interface provides
the contract between the JT and various schedulers (see HADOOP-3412). Having something else
sit between the JT and various schedulers violates this contract. 
* We haven't really considered a 'meta scheduler' - what it is, what it does, whether it's
needed. You're welcome to start a Jira on this issue. A meta-scheduler would, presumably,
affect all schedulers, so what is it that you'd like it to do? Is there some functionality
 that might be better suited for the JT, perhaps? 
* Most importantly, the functionality you desire (affecting how priorities are changed for
jobs) may not be something that all schedulers want. In fact, it is not something we want
to currently do for the Capacity Scheduler. The requirements for the CapacityScheduler, as
listed in HADOOP-3421, allow users to change job priorities anytime, and we have certain guarantees
in terms of what happens when priorities of running or waiting jobs are changed. As things
stand, your patch will cause the CapacityScheduler to behave differently from what it's supposed
to do. 

You can also file separate Jiras for individually modifying the functionality of the Capacity
and Fairshare schedulers (as Matei correctly points out, they do have different requirements
and philosophies), but I'd recommend that you provide some use cases and examples of why the
existing functionality is not good enough or what exactly is missing. With respect to the
Capacity Scheduler, we have had a few discussions on resource budgets and penalizing/rewarding
users based on their prior resource consumptions, but we currently don't have any concrete

On a related note, you may be wanting to re-use much of the implementation of the Capacity
or Fairshare schedulers. This issue has come up before and we would like to make it easy to
share code, but it's a separate issue with a separate discussion (I can't remember if we have
a Jira filed for it). 

> Dynamic Priority Scheduler that allows queue shares to be controlled dynamically by a
> ----------------------------------------------------------------------------------------------
>                 Key: HADOOP-4768
>                 URL: https://issues.apache.org/jira/browse/HADOOP-4768
>             Project: Hadoop Core
>          Issue Type: New Feature
>          Components: contrib/capacity-sched, contrib/fair-share
>    Affects Versions: 0.20.0
>            Reporter: Thomas Sandholm
>            Assignee: Thomas Sandholm
>             Fix For: 0.20.0
>         Attachments: HADOOP-4768-capacity-scheduler.patch, HADOOP-4768-dynamic-scheduler.patch,
HADOOP-4768-fairshare.patch, HADOOP-4768.patch
> Contribution based on work presented at the Hadoop User Group meeting in Santa Clara
in September and the HadoopCamp in New Orleans in November.
> From README:
> This package implements dynamic priority scheduling for MapReduce jobs.
> Overview
> --------
> The purpose of this scheduler is to allow users to increase and decrease
> their queue priorities continuosly to meet the requirements of their
> current workloads. The scheduler is aware of the current demand and makes
> it more expensive to boost the priority under peak usage times. Thus
> users who move their workload to low usage times are rewarded with
> discounts. Priorities can only be boosted within a limited quota.
> All users are given a quota or a budget which is deducted periodically
> in configurable accounting intervals. How much of the budget is 
> deducted is determined by a per-user spending rate, which may
> be modified at any time directly by the user. The cluster slots 
> share allocated to a particular user is computed as that users
> spending rate over the sum of all spending rates in the same accounting
> period.
> Configuration
> -------------
> This scheduler has been designed as a meta-scheduler on top of 
> existing MapReduce schedulers, which are responsible for enforcing
> shares computed by the dynamic scheduler in the cluster. Thie configuration
> of this MapReduce scheduler does not have to change when deploying
> the dynamic scheduler.
> Hadoop Configuration (e.g. hadoop-site.xml):
> mapred.jobtracker.taskScheduler      This needs to be set to 
>                                      org.apache.hadoop.mapred.DynamicPriorityScheduler
>                                      to use the dynamic scheduler.
> mapred.queue.names                   All queues managed by the dynamic scheduler must
be listed
>                                      here (comma separated no spaces)
> Scheduler Configuration:
> mapred.dynamic-scheduler.scheduler   The Java path of the MapReduce scheduler that should
>                                      enforce the allocated shares.
>                                      Has been tested with:
>                                      org.apache.hadoop.mapred.FairScheduler
>                                      and
>                                      org.apache.hadoop.mapred.CapacityTaskScheduler
> mapred.dynamic-scheduler.budgetfile  The full OS path of the file from which the
>                                      budgets are read. The synatx of this file is:
>                                      <queueName> <budget>
>                                      separated by newlines where budget can be specified
>                                      as a Java float
> mapred.dynamic-scheduler.spendfile   The full OS path of the file from which the
>                                      user/queue spending rate is read. It allows
>                                      the queue name to be placed into the path
>                                      at runtime, e.g.:
>                                      /home/%QUEUE%/.spending
>                                      Only the user(s) who submit jobs to the
>                                      specified queue should have write access
>                                      to this file. The syntax of the file is
>                                      just:
>                                      <spending rate>
>                                      where the spending rate is specified as a
>                                      Java float. If no spending rate is specified
>                                      the rate defaults to budget/1000.
> mapred.dynamic-scheduler.alloc       Allocation interval, when the scheduler rereads
>                                      spending rates and recalculates the cluster shares.
>                                      Specified as seconds between allocations.
>                                      Default is 20 seconds.
> mapred.dynamic-scheduler.budgetset   Boolean which is true if the budget should be deducted

>                                      by the scheduler and the updated budget written
to the
>                                      budget file. Default is true. Setting this to false
>                                      useful if there is a tool that controls budgets
>                                      spending rates externally to the scheduler.
> Runtime Configuration:
> mapred.scheduler.shares              The shares that should be allocated to the specified
>                                      The configuration property is a comma separated
list of
>                                      strings where the odd positioned elements are the

>                                      queue names and the even positioned elements are
the shares
>                                      as Java floats of the preceding queue name. It is
>                                      for all the queues atomically in each allocation
pass. MapReduce
>                                      schedulers such as the Fair and CapacityTask schedulers
>                                      are expected to read from this property periodically.
>                                      Example property value: "queue1,45.0,queue2,55.0"

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message