[
https://issues.apache.org/jira/browse/YARN-6775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078677#comment-16078677
]
Nathan Roberts commented on YARN-6775:
--------------------------------------
Below is the list of changes included in the patch. Each is prefixed with the
new throughput number as reported by the included unit test case. (Run as: mvn
test -Dtest=TestCapacityScheduler#testUserLimitThroughput
-DRunUserLimitThroughput=true)
* 13500 - Baseline (baseline was 9100 prior to Daryn's set of improvements in
YARN-6242)
* 15000 - In computeUserLimitAndSetHeaderoom(), calculating headroom is not
cheap so only do so if user metrics are enabled - which is the only thing that
depends on the result of getHeadroom().
* 20000 - cache userlimit calculation within assignContainers() + Avoid
canAssignToQueue() check if we've already calculated the worst-case condition
(no possibility of freeing up a reservation to satisfy the request)
* 24000 - Avoid canAssignToUser() if we've already determined this user is over
its limit given the current application's reservation request
* 53000 - Check for shouldRecordThisNode() earlier in
recordRejectedAppActivityFromLeafQueue() to avoid expensive calculations that
will just be thrown away later
> CapacityScheduler: Improvements to assignContainers()
> -----------------------------------------------------
>
> Key: YARN-6775
> URL: https://issues.apache.org/jira/browse/YARN-6775
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: capacityscheduler
> Affects Versions: 2.8.1, 3.0.0-alpha3
> Reporter: Nathan Roberts
> Assignee: Nathan Roberts
> Attachments: YARN-6775.001.patch
>
>
> There are several things in assignContainers() that are done multiple times
> even though the result cannot change (canAssignToUser, canAssignToQueue). Add
> some local caching to take advantage of this fact.
> Will post patch shortly. Patch includes a simple throughput test that
> demonstrates when we have users at their user-limit, the number of
> NodeUpdateSchedulerEvents we can process can be improved from 13K/sec to
> 50K/sec.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
