[ 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: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org