Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: yarn-issues@hadoop.apache.org
Date: Mon, 3 Mar 2014 15:15:21 +0000 (UTC)
From: "Thomas Graves (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12698002.1393617676782.3092.1393859721527@arcas>
In-Reply-To: <JIRA.12698002.1393617676782@arcas>
References: <JIRA.12698002.1393617676782@arcas>
Subject: [jira] [Updated] (YARN-1769) CapacityScheduler:  Improve
 reservations
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/YARN-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Graves updated YARN-1769:
--------------------------------

    Attachment: YARN-1769.patch

In this patch I tried to minimize the code changes.  I choose to keep the accounting/book keeping of reservations the same to hopefully minimize the impact of this and keep it small.   I made this change configurable (which is refreshable via yarn rmadmin -refreshQueues). 

At a high level what it does is:

- for the limit checks, it does the normal checks but then if it has hit a limit and this is configured on, it does the check again subtracting out the amount reserved.  If that is under the limit it allows it to go on to see if it could unreserve a spot and use the current node.

- for the number of reservation limit, we simply delay that check and if we could allocate on the current node by unreserving then we do.


> CapacityScheduler:  Improve reservations
> ----------------------------------------
>
>                 Key: YARN-1769
>                 URL: https://issues.apache.org/jira/browse/YARN-1769
>             Project: Hadoop YARN
>          Issue Type: Improvement
>          Components: capacityscheduler
>    Affects Versions: 2.3.0
>            Reporter: Thomas Graves
>            Assignee: Thomas Graves
>         Attachments: YARN-1769.patch
>
>
> Currently the CapacityScheduler uses reservations in order to handle requests for large containers and the fact there might not currently be enough space available on a single host.
> The current algorithm for reservations is to reserve as many containers as currently required and then it will start to reserve more above that after a certain number of re-reservations (currently biased against larger containers).  Anytime it hits the limit of number reserved it stops looking at any other nodes. This results in potentially missing nodes that have enough space to fullfill the request.   
> The other place for improvement is currently reservations count against your queue capacity.  If you have reservations you could hit the various limits which would then stop you from looking further at that node.  
> The above 2 cases can cause an application requesting a larger container to take a long time to gets it resources.  
> We could improve upon both of those by simply continuing to look at incoming nodes to see if we could potentially swap out a reservation for an actual allocation. 


--
This message was sent by Atlassian JIRA
(v6.2#6252)