[
https://issues.apache.org/jira/browse/YARN-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16119135#comment-16119135
]
Steven Rand commented on YARN-6956:
-----------------------------------
Hi [~kasha], thanks for the suggestions. I would definitely like to contribute.
A couple questions to make sure I understand:
* For prioritizing the RR to check, does that mean sorting the RRs for an app
by the value of {{getPriority()}}, and checking the highest priority one first?
And if there are multiple RRs with the same priority, the suggestion is to
choose the one that's requesting the least number of resources? If so, how do
we avoid preempting small amounts at a time, and taking a long time to satisfy
starvation? Or is it the responsibility of the app to not prioritize many small
RRs?
* Considering more than one RR definitely seems like a good idea. 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? (Assuming of course that there
is at least one such RR.)
* Honoring delay scheduling for preemption makes sense -- I don't have any
questions about that one.
> 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: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
