[
https://issues.apache.org/jira/browse/AURORA-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Khutornenko updated AURORA-1156:
--------------------------------------
Sprint: Twitter Aurora Q1'15 Sprint 4
> Preemptor perf improvements
> ---------------------------
>
> Key: AURORA-1156
> URL: https://issues.apache.org/jira/browse/AURORA-1156
> Project: Aurora
> Issue Type: Task
> Components: Scheduler
> Reporter: Maxim Khutornenko
> Assignee: Maxim Khutornenko
>
> There are two minor algorithm changes that should result in overall preemptor
> perf improvements:
> 1. There seems to be a redundant scheduling attempt here: \[1\]. The
> preemptor loop is triggered within the same storage write lock right after a
> failed {{OfferManager.launchFirst()}} run that has already attempted to match
> all available offers. There is no reason to attempt another match given the
> same system conditions, especially considering that a positive scheduling
> result from this loop is discarded anyway \[2\].
> 2. Instead of running an expensive scheduling loop \[3\] for every task
> victim, it's possible to "size up" victim resources and call scheduling
> filter only when rough resource estimates are sufficient. Something like:
> {noformat}
> if (totalResource.greaterOrEqualThan(ResourceSlot.from(pendingTask))) {
> // call schedulingFilter
> }
> {noformat}
> \[1\] -
> https://github.com/apache/incubator-aurora/blob/master/src/main/java/org/apache/aurora/scheduler/async/preemptor/PreemptorImpl.java#L220-L237
> \[2\] -
> https://github.com/apache/incubator-aurora/blob/master/src/main/java/org/apache/aurora/scheduler/async/preemptor/PreemptorImpl.java#L338
> \[3\] -
> https://github.com/apache/incubator-aurora/blob/master/src/main/java/org/apache/aurora/scheduler/async/preemptor/PreemptorImpl.java#L263-L265
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
