[
https://issues.apache.org/jira/browse/YARN-8292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16478000#comment-16478000
]
Eric Payne commented on YARN-8292:
----------------------------------
{quote}
||Queue||Guaranteed||Used ||Pending||
|A|<20, 10>|<20,30>| |
|B|<20, 10>|0|0|
|C|<20, 10>|0|<20, 30>|
Under current logic, A's calculated to-preempt (how much resource other queue
can preempt) will be <0, 20>. The preemption will not happen.
{quote}
I want to challenge the original example. The above does cause preemption. I
have tested this scenario, and it does preempt.
In my tests, the first resource is memory and the second is vcores. I think the
reason is that the dominant resource calculator will determine that vcores is a
higher percentage of the available resources than memory, so vcores is dominant.
> Fix the dominant resource preemption cannot happen when some of the resource
> vector becomes negative
> ----------------------------------------------------------------------------------------------------
>
> Key: YARN-8292
> URL: https://issues.apache.org/jira/browse/YARN-8292
> Project: Hadoop YARN
> Issue Type: Bug
> Components: yarn
> Reporter: Sumana Sathish
> Assignee: Wangda Tan
> Priority: Critical
> Fix For: 3.2.0, 3.1.1
>
> Attachments: YARN-8292.001.patch
>
>
>
> This is an example of the problem: (Same if we have more than 2 resources)
>
> Let's say we have 3 queues A/B/C. All containers with equal size <2,3>
>
> ||Queue||Guaranteed||Used ||Pending||
> |A|<20, 10>|<20,30>| |
> |B|<20, 10>|0|0|
> |C|<20, 10>|0|<20, 30>|
> | | | | |
>
> Under current logic, A's calculated to-preempt (how much resource other queue
> can preempt) will be <0, 20>. The preemption will not happen. However, under
> the context of DRC, queue A is using more resource than guaranteed, so queue
> C will be starved
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
