hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karthik Kambatla (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-3655) FairScheduler: potential livelock due to maxAMShare limitation and container reservation
Date Wed, 20 May 2015 00:00:00 GMT

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

Karthik Kambatla commented on YARN-3655:
----------------------------------------

If allocating a container is going to take the amShare over the maxAMShare, not allocating
and hence unreserving resources seems reasonable. That said, we should also add the same check
before making such a reservation in FSAppAttempt#assignContainer.

There is already a check to ensure we won't go over maxShare. In terms of code organization,
I would like for us to create a helper method (okayToReserveResources) that would check the
maxShare for all containers and maxAMShare for AM containers. 

Also, looking at the code, I see fitsInMaxShare method is a static in FairScheduler. We should
just make it a non-static method in FSQueue, it can call parent.fitsInMaxShare. Can we file
a follow-up JIRA for it? 

> FairScheduler: potential livelock due to maxAMShare limitation and container reservation

> -----------------------------------------------------------------------------------------
>
>                 Key: YARN-3655
>                 URL: https://issues.apache.org/jira/browse/YARN-3655
>             Project: Hadoop YARN
>          Issue Type: Bug
>          Components: fairscheduler
>    Affects Versions: 2.7.0
>            Reporter: zhihai xu
>            Assignee: zhihai xu
>         Attachments: YARN-3655.000.patch, YARN-3655.001.patch
>
>
> FairScheduler: potential livelock due to maxAMShare limitation and container reservation.
> If a node is reserved by an application, all the other applications don't have any chance
to assign a new container on this node, unless the application which reserves the node assigns
a new container on this node or releases the reserved container on this node.
> The problem is if an application tries to call assignReservedContainer and fail to get
a new container due to maxAMShare limitation, it will block all other applications to use
the nodes it reserves. If all other running applications can't release their AM containers
due to being blocked by these reserved containers. A livelock situation can happen.
> The following is the code at FSAppAttempt#assignContainer which can cause this potential
livelock.
> {code}
>     // Check the AM resource usage for the leaf queue
>     if (!isAmRunning() && !getUnmanagedAM()) {
>       List<ResourceRequest> ask = appSchedulingInfo.getAllResourceRequests();
>       if (ask.isEmpty() || !getQueue().canRunAppAM(
>           ask.get(0).getCapability())) {
>         if (LOG.isDebugEnabled()) {
>           LOG.debug("Skipping allocation because maxAMShare limit would " +
>               "be exceeded");
>         }
>         return Resources.none();
>       }
>     }
> {code}
> To fix this issue, we can unreserve the node if we can't allocate the AM container on
the node due to Max AM share limitation and the node is reserved by the application.



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

Mime
View raw message