[
https://issues.apache.org/jira/browse/YARN-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Abdelnur updated YARN-689:
------------------------------------
Attachment: YARN-689.patch
[~acmurthy], regarding your last comment. Unless I'm missing something, if
today you set the minimum to 128M, you run into the issue you describe "then
trying to get reservations to work for 1.7G v/s 1.9G on can be very hard.
Worse, this leads to lots of nodes with <1G fragments leading to poor
utilization.". No?
Anyway, as having {{increment}} decoupled from {{minimum}} outside of FS seems
to the the issue, updating with a patch doing what Tom suggested: For CS and
FIFO {{increment}} is hardwired to {{minimum}}.
Also, added a testcase with minicluster running with FS to verify the increment
makes it to the AMRMClient correctly.
> Add multiplier unit to resourcecapabilities
> -------------------------------------------
>
> Key: YARN-689
> URL: https://issues.apache.org/jira/browse/YARN-689
> Project: Hadoop YARN
> Issue Type: Bug
> Components: api, scheduler
> Affects Versions: 2.0.4-alpha
> Reporter: Alejandro Abdelnur
> Assignee: Alejandro Abdelnur
> Attachments: YARN-689.patch, YARN-689.patch, YARN-689.patch,
> YARN-689.patch, YARN-689.patch
>
>
> Currently we overloading the minimum resource value as the actual multiplier
> used by the scheduler.
> Today with a minimum memory set to 1GB, requests for 1.5GB are always
> translated to allocation of 2GB.
> We should decouple the minimum allocation from the multiplier.
> The multiplier should also be exposed to the client via the
> RegisterApplicationMasterResponse
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
