Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 26 May 2016 07:10:12 +0000 (UTC)
From: "Karthik Kambatla (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12969321.1463077649000.300760.1464246612895@Atlassian.JIRA>
In-Reply-To: <JIRA.12969321.1463077649000@Atlassian.JIRA>
References: <JIRA.12969321.1463077649000@Atlassian.JIRA> <JIRA.12969321.1463077649211@arcas>
Subject: [jira] [Commented] (YARN-5077) Fix FSLeafQueue#getFairShare() for
 queues with weight 0.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 26 May 2016 07:10:15 -0000


    [ https://issues.apache.org/jira/browse/YARN-5077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15301649#comment-15301649 ] 

Karthik Kambatla commented on YARN-5077:
----------------------------------------

Actually, thinking more about this, I am beginning to doubt our initial approach. Or, it has just been a long day. 

A queue should get resources assigned even if the fairshare is zero. However, the AM cannot be spawned because the maxAMShare is zero if the fairshare is zero. [~yufeigu] - can you confirm if this is the case? 

If this is indeed the case, we should probably look at this maxAMShare thing more comprehensively. 


> Fix FSLeafQueue#getFairShare() for queues with weight 0.0
> ---------------------------------------------------------
>
>                 Key: YARN-5077
>                 URL: https://issues.apache.org/jira/browse/YARN-5077
>             Project: Hadoop YARN
>          Issue Type: Bug
>            Reporter: Yufei Gu
>            Assignee: Yufei Gu
>         Attachments: YARN-5077.001.patch, YARN-5077.002.patch, YARN-5077.003.patch, YARN-5077.004.patch, YARN-5077.005.patch
>
>
> 1) When a queue's weight is set to 0.0, FSLeafQueue#getFairShare() returns <memory:0, vCores:0> 
> 2) When a queue's weight is nonzero, FSLeafQueue#getFairShare() returns <memory:16384, vCores:8>
> In case 1), that means no container ever gets allocated for an AM because from the viewpoint of the RM, there is never any headroom to allocate a container on that queue.
> For example, we have a pool with the following weights: 
> - root.dev 0.0 
> - root.product 1.0
> The root.dev is a best effort pool and should only get resources if root.product is not running. In our tests, with no jobs running under root.product, jobs started in root.dev queue stay stuck in ACCEPT phase and never start.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org