[
https://issues.apache.org/jira/browse/YARN-4390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15260985#comment-15260985
]
Eric Payne commented on YARN-4390:
----------------------------------
[~leftnoteasy],
{quote}
have you set following config?
{code}
<property>
<name>yarn.resourcemanager.monitor.capacity.preemption.select_based_on_reserved_containers</name>
<value>true</value>
</property>
{code}
{quote}
Yup! :-) I double checked and that parameter is definitely set in my
environment.
bq. 1) total_preemption_per_round should make sure that, each round needs
preempt enough resource to allocate one large container
preemption per round is set to 100%
bq. 2) before ver.7, natural_termination_factor should set to 1 to make sure
enough resources will be preempted.
That was it! I set natural termination factor to 1.0 and it's working more in
line with what I expect. I was not setting natural termination factor.
Unfortunately, when I applied YARN-4390.7.patch, I still need to set the
natural termination factor in order to get the expected results. If I just
leave that parameter out of my config and let it go to the default, the
behavior is the same as in version 6 of the patch. That is, the app requesting
larger containers can never use more than about 68% of the {{ops}} queue, and
the app running on the preemptable queue has more than 100 containers
preempted, only to be given back to the same app.
> Do surgical preemption based on reserved container in CapacityScheduler
> -----------------------------------------------------------------------
>
> Key: YARN-4390
> URL: https://issues.apache.org/jira/browse/YARN-4390
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: capacity scheduler
> Affects Versions: 3.0.0, 2.8.0, 2.7.3
> Reporter: Eric Payne
> Assignee: Wangda Tan
> Attachments: QueueNotHittingMax.jpg, YARN-4390-design.1.pdf,
> YARN-4390-test-results.pdf, YARN-4390.1.patch, YARN-4390.2.patch,
> YARN-4390.3.branch-2.patch, YARN-4390.3.patch, YARN-4390.4.patch,
> YARN-4390.5.patch, YARN-4390.6.patch, YARN-4390.7.patch
>
>
> There are multiple reasons why preemption could unnecessarily preempt
> containers. One is that an app could be requesting a large container (say
> 8-GB), and the preemption monitor could conceivably preempt multiple
> containers (say 8, 1-GB containers) in order to fill the large container
> request. These smaller containers would then be rejected by the requesting AM
> and potentially given right back to the preempted app.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
