[ https://issues.apache.org/jira/browse/YARN-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13919161#comment-13919161 ]
Sunil G commented on YARN-1769: ------------------------------- Hi Thomas In LeafQueue assignContainer call, reserve() call will happen from the else logic. Here there is a check as below if ((!scheduler.getConfiguration().getReservationContinueLook()) || (canAllocContainer) || (rmContainer != null)) { Is there any scenrio to happen with out these 3 case. ? Only if for first time allocation, and if application cant assign a container, may be chances are less to reach here. > CapacityScheduler: Improve reservations > ---------------------------------------- > > Key: YARN-1769 > URL: https://issues.apache.org/jira/browse/YARN-1769 > Project: Hadoop YARN > Issue Type: Improvement > Components: capacityscheduler > Affects Versions: 2.3.0 > Reporter: Thomas Graves > Assignee: Thomas Graves > Attachments: YARN-1769.patch > > > Currently the CapacityScheduler uses reservations in order to handle requests > for large containers and the fact there might not currently be enough space > available on a single host. > The current algorithm for reservations is to reserve as many containers as > currently required and then it will start to reserve more above that after a > certain number of re-reservations (currently biased against larger > containers). Anytime it hits the limit of number reserved it stops looking > at any other nodes. This results in potentially missing nodes that have > enough space to fullfill the request. > The other place for improvement is currently reservations count against your > queue capacity. If you have reservations you could hit the various limits > which would then stop you from looking further at that node. > The above 2 cases can cause an application requesting a larger container to > take a long time to gets it resources. > We could improve upon both of those by simply continuing to look at incoming > nodes to see if we could potentially swap out a reservation for an actual > allocation. -- This message was sent by Atlassian JIRA (v6.2#6252)