[
https://issues.apache.org/jira/browse/YARN-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124069#comment-16124069
]
Karthik Kambatla commented on YARN-6956:
----------------------------------------
bq. If so, how do we avoid preempting small amounts at a time, and taking a
long time to satisfy starvation?
This is a tradeoff. If we want to avoid large capacity requests getting stuck
and blocking rest of the container requests, we will have to look at the small
capacity requests first.
bq. Is it reasonable to make sure to include at least one RR for which locality
is relaxed, and/or the RR is for a rack or * in the list of RRs that we check,
even if that means checking a lower-priority RR?
The relaxed locality versions should probably be considered based on delay
scheduling configs. And, it is not clear whether to consider lower priority
ones or not. Maybe, we can start with not considering and revisit based on how
things fare in production.
> preemption may only consider resource requests for one node
> -----------------------------------------------------------
>
> Key: YARN-6956
> URL: https://issues.apache.org/jira/browse/YARN-6956
> Project: Hadoop YARN
> Issue Type: Bug
> Components: fairscheduler
> Affects Versions: 2.9.0, 3.0.0-beta1
> Environment: CDH 5.11.0
> Reporter: Steven Rand
>
> I'm observing the following series of events on a CDH 5.11.0 cluster, which
> seem to be possible after YARN-6163:
> 1. An application is considered to be starved, so {{FSPreemptionThread}}
> calls {{identifyContainersToPreempt}}, and that calls
> {{FSAppAttempt#getStarvedResourceRequests}} to get a list of
> {{ResourceRequest}} instances that are enough to address the app's starvation.
> 2. The first {{ResourceRequest}} that {{getStarvedResourceRequests}} sees is
> enough to address the app's starvation, so we break out of the loop over
> {{appSchedulingInfo.getAllResourceRequests()}} after only one iteration:
> https://github.com/apache/hadoop/blob/trunk/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/fair/FSAppAttempt.java#L1180.
> We return only this one {{ResourceRequest}} back to the
> {{identifyContainersToPreempt}} method.
> 3. It turns out that this particular {{ResourceRequest}} happens to have a
> value for {{getResourceName}} that identifies a specific node in the cluster.
> This causes preemption to only consider containers on that node, and not the
> rest of the cluster.
> [~kasha], does that make sense? I'm happy to submit a patch if I'm
> understanding the problem correctly.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
