You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@mesos.apache.org by Neil Conway <ne...@gmail.com> on 2016/03/02 03:22:42 UTC
Review Request 44251: Improved allocator perf for labeled
reservations and volumes.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/44251/
-----------------------------------------------------------
Review request for mesos and Joris Van Remoortere.
Bugs: MESOS-4833
https://issues.apache.org/jira/browse/MESOS-4833
Repository: mesos
Description
-------
When the cluster contains many resources that have either labeled
reservations or persistent volumes, allocator performance can decrease
substantially because such metadata prevents `Resource` objects from
being merged together inside the allocator. As a result, the allocator
must manipulate `Resources` vectors that consist of many small
individual `Resource` values; since many `Resources` operations take
linear-time in the number of `Resource` values they contain, this can
cause very significant slowdowns.
As a short-term solution, this commit strips dynamic reservation and
persistent volume information from the `Resources` objects used
internally by the allocator, because they are not needed when
aggregating resource quantities together.
A long-term solution for this problem will be addressed as work on
refactoring the allocator more generally.
Diffs
-----
src/master/allocator/mesos/hierarchical.cpp 24fa50f62dec10ed43089297473cc386d6ba2f78
src/master/allocator/sorter/drf/sorter.hpp 46b2a9caf13b028a3aee6c1590679f885be90fd6
src/master/allocator/sorter/drf/sorter.cpp 9e863dd0ca5e2f2f0d517cb833687b757bed2c52
src/master/allocator/sorter/sorter.hpp ba91a38e47065718af87c9b3b7c5b74d25a258df
Diff: https://reviews.apache.org/r/44251/diff/
Testing
-------
make check
Perf:
```
[ RUN ] HierarchicalAllocator_BENCHMARK_Test.ResourceLabels
Using 2000 slaves and 200 frameworks
round 0 allocate took 2.458462secs to make 200 offers
round 1 allocate took 2.427941secs to make 200 offers
round 2 allocate took 2.460724secs to make 200 offers
round 3 allocate took 2.443408secs to make 200 offers
round 4 allocate took 2.464784secs to make 200 offers
round 5 allocate took 2.501429secs to make 200 offers
round 6 allocate took 2.468777secs to make 200 offers
round 7 allocate took 2.482268secs to make 200 offers
round 8 allocate took 2.479014secs to make 200 offers
round 9 allocate took 2.529951secs to make 200 offers
round 10 allocate took 2.460059secs to make 200 offers
```
Performance of `DeclineOffers` without labels is about ~2.1 seconds.
Thanks,
Neil Conway
Re: Review Request 44251: Improved allocator perf for labeled
reservations and volumes.
Posted by Joris Van Remoortere <jo...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/44251/#review121588
-----------------------------------------------------------
src/master/allocator/mesos/hierarchical.cpp (line 1226)
<https://reviews.apache.org/r/44251/#comment183324>
should we use __quantity__ as you changed it above as well?
src/master/allocator/mesos/hierarchical.cpp (lines 1349 - 1350)
<https://reviews.apache.org/r/44251/#comment183326>
Can we add a comment explaining that `allocatedStage2` is now a __quantity__, and that this invariant is maintained by only adding `StrippedScalarQuantity`s to it?
src/master/allocator/sorter/drf/sorter.cpp (lines 374 - 375)
<https://reviews.apache.org/r/44251/#comment183328>
new line?
- Joris Van Remoortere
On March 2, 2016, 2:22 a.m., Neil Conway wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44251/
> -----------------------------------------------------------
>
> (Updated March 2, 2016, 2:22 a.m.)
>
>
> Review request for mesos and Joris Van Remoortere.
>
>
> Bugs: MESOS-4833
> https://issues.apache.org/jira/browse/MESOS-4833
>
>
> Repository: mesos
>
>
> Description
> -------
>
> When the cluster contains many resources that have either labeled
> reservations or persistent volumes, allocator performance can decrease
> substantially because such metadata prevents `Resource` objects from
> being merged together inside the allocator. As a result, the allocator
> must manipulate `Resources` vectors that consist of many small
> individual `Resource` values; since many `Resources` operations take
> linear-time in the number of `Resource` values they contain, this can
> cause very significant slowdowns.
>
> As a short-term solution, this commit strips dynamic reservation and
> persistent volume information from the `Resources` objects used
> internally by the allocator, because they are not needed when
> aggregating resource quantities together.
>
> A long-term solution for this problem will be addressed as work on
> refactoring the allocator more generally.
>
>
> Diffs
> -----
>
> src/master/allocator/mesos/hierarchical.cpp 24fa50f62dec10ed43089297473cc386d6ba2f78
> src/master/allocator/sorter/drf/sorter.hpp 46b2a9caf13b028a3aee6c1590679f885be90fd6
> src/master/allocator/sorter/drf/sorter.cpp 9e863dd0ca5e2f2f0d517cb833687b757bed2c52
> src/master/allocator/sorter/sorter.hpp ba91a38e47065718af87c9b3b7c5b74d25a258df
>
> Diff: https://reviews.apache.org/r/44251/diff/
>
>
> Testing
> -------
>
> make check
>
> Perf:
>
> ```
> [ RUN ] HierarchicalAllocator_BENCHMARK_Test.ResourceLabels
> Using 2000 slaves and 200 frameworks
> round 0 allocate took 2.458462secs to make 200 offers
> round 1 allocate took 2.427941secs to make 200 offers
> round 2 allocate took 2.460724secs to make 200 offers
> round 3 allocate took 2.443408secs to make 200 offers
> round 4 allocate took 2.464784secs to make 200 offers
> round 5 allocate took 2.501429secs to make 200 offers
> round 6 allocate took 2.468777secs to make 200 offers
> round 7 allocate took 2.482268secs to make 200 offers
> round 8 allocate took 2.479014secs to make 200 offers
> round 9 allocate took 2.529951secs to make 200 offers
> round 10 allocate took 2.460059secs to make 200 offers
> ```
>
> Performance of `DeclineOffers` without labels is about ~2.1 seconds.
>
>
> Thanks,
>
> Neil Conway
>
>
Re: Review Request 44251: Improved allocator perf for labeled
reservations and volumes.
Posted by Neil Conway <ne...@gmail.com>.
> On March 2, 2016, 1:11 p.m., Guangya Liu wrote:
> > src/master/allocator/mesos/hierarchical.cpp, line 1421
> > <https://reviews.apache.org/r/44251/diff/2/?file=1276336#file1276336line1421>
> >
> > One suggestion is that does it make sense to update all variables including `scalar` to `strippedScalar` which might be more accurate.
Thanks -- I decided to go with `scalarQuantity`.
- Neil
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/44251/#review121633
-----------------------------------------------------------
On March 2, 2016, 7:15 p.m., Neil Conway wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44251/
> -----------------------------------------------------------
>
> (Updated March 2, 2016, 7:15 p.m.)
>
>
> Review request for mesos and Joris Van Remoortere.
>
>
> Bugs: MESOS-4833
> https://issues.apache.org/jira/browse/MESOS-4833
>
>
> Repository: mesos
>
>
> Description
> -------
>
> When the cluster contains many resources that have either labeled
> reservations or persistent volumes, allocator performance can decrease
> substantially because such metadata prevents `Resource` objects from
> being merged together inside the allocator. As a result, the allocator
> must manipulate `Resources` vectors that consist of many small
> individual `Resource` values; since many `Resources` operations take
> linear-time in the number of `Resource` values they contain, this can
> cause very significant slowdowns.
>
> As a short-term solution, this commit strips dynamic reservation and
> persistent volume information from the `Resources` objects used
> internally by the allocator, because they are not needed when
> aggregating resource quantities together.
>
> A long-term solution for this problem will be addressed as work on
> refactoring the allocator more generally.
>
>
> Diffs
> -----
>
> src/master/allocator/mesos/hierarchical.cpp 24fa50f62dec10ed43089297473cc386d6ba2f78
> src/master/allocator/sorter/drf/sorter.hpp 46b2a9caf13b028a3aee6c1590679f885be90fd6
> src/master/allocator/sorter/drf/sorter.cpp 9e863dd0ca5e2f2f0d517cb833687b757bed2c52
> src/master/allocator/sorter/sorter.hpp ba91a38e47065718af87c9b3b7c5b74d25a258df
>
> Diff: https://reviews.apache.org/r/44251/diff/
>
>
> Testing
> -------
>
> make check
>
> Perf:
>
> ```
> [ RUN ] HierarchicalAllocator_BENCHMARK_Test.ResourceLabels
> Using 2000 slaves and 200 frameworks
> round 0 allocate took 2.458462secs to make 200 offers
> round 1 allocate took 2.427941secs to make 200 offers
> round 2 allocate took 2.460724secs to make 200 offers
> round 3 allocate took 2.443408secs to make 200 offers
> round 4 allocate took 2.464784secs to make 200 offers
> round 5 allocate took 2.501429secs to make 200 offers
> round 6 allocate took 2.468777secs to make 200 offers
> round 7 allocate took 2.482268secs to make 200 offers
> round 8 allocate took 2.479014secs to make 200 offers
> round 9 allocate took 2.529951secs to make 200 offers
> round 10 allocate took 2.460059secs to make 200 offers
> ```
>
> Performance of `DeclineOffers` without labels is about ~2.1 seconds.
>
>
> Thanks,
>
> Neil Conway
>
>
Re: Review Request 44251: Improved allocator perf for labeled
reservations and volumes.
Posted by Guangya Liu <gy...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/44251/#review121633
-----------------------------------------------------------
src/master/allocator/mesos/hierarchical.cpp (line 1419)
<https://reviews.apache.org/r/44251/#comment183381>
One suggestion is that does it make sense to update all variables including `scalar` to `strippedScalar` which might be more accurate.
- Guangya Liu
On 三月 2, 2016, 6:21 a.m., Neil Conway wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44251/
> -----------------------------------------------------------
>
> (Updated 三月 2, 2016, 6:21 a.m.)
>
>
> Review request for mesos and Joris Van Remoortere.
>
>
> Bugs: MESOS-4833
> https://issues.apache.org/jira/browse/MESOS-4833
>
>
> Repository: mesos
>
>
> Description
> -------
>
> When the cluster contains many resources that have either labeled
> reservations or persistent volumes, allocator performance can decrease
> substantially because such metadata prevents `Resource` objects from
> being merged together inside the allocator. As a result, the allocator
> must manipulate `Resources` vectors that consist of many small
> individual `Resource` values; since many `Resources` operations take
> linear-time in the number of `Resource` values they contain, this can
> cause very significant slowdowns.
>
> As a short-term solution, this commit strips dynamic reservation and
> persistent volume information from the `Resources` objects used
> internally by the allocator, because they are not needed when
> aggregating resource quantities together.
>
> A long-term solution for this problem will be addressed as work on
> refactoring the allocator more generally.
>
>
> Diffs
> -----
>
> src/master/allocator/mesos/hierarchical.cpp 24fa50f62dec10ed43089297473cc386d6ba2f78
> src/master/allocator/sorter/drf/sorter.hpp 46b2a9caf13b028a3aee6c1590679f885be90fd6
> src/master/allocator/sorter/drf/sorter.cpp 9e863dd0ca5e2f2f0d517cb833687b757bed2c52
> src/master/allocator/sorter/sorter.hpp ba91a38e47065718af87c9b3b7c5b74d25a258df
>
> Diff: https://reviews.apache.org/r/44251/diff/
>
>
> Testing
> -------
>
> make check
>
> Perf:
>
> ```
> [ RUN ] HierarchicalAllocator_BENCHMARK_Test.ResourceLabels
> Using 2000 slaves and 200 frameworks
> round 0 allocate took 2.458462secs to make 200 offers
> round 1 allocate took 2.427941secs to make 200 offers
> round 2 allocate took 2.460724secs to make 200 offers
> round 3 allocate took 2.443408secs to make 200 offers
> round 4 allocate took 2.464784secs to make 200 offers
> round 5 allocate took 2.501429secs to make 200 offers
> round 6 allocate took 2.468777secs to make 200 offers
> round 7 allocate took 2.482268secs to make 200 offers
> round 8 allocate took 2.479014secs to make 200 offers
> round 9 allocate took 2.529951secs to make 200 offers
> round 10 allocate took 2.460059secs to make 200 offers
> ```
>
> Performance of `DeclineOffers` without labels is about ~2.1 seconds.
>
>
> Thanks,
>
> Neil Conway
>
>
Re: Review Request 44251: Improved allocator perf for labeled
reservations and volumes.
Posted by Mesos ReviewBot <re...@mesos.apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/44251/#review121628
-----------------------------------------------------------
Patch looks great!
Reviews applied: [43684, 43685, 43686, 44250, 44251]
Passed command: export OS='ubuntu:14.04' CONFIGURATION='--verbose' COMPILER='gcc' ENVIRONMENT='GLOG_v=1 MESOS_VERBOSE=1'; ./support/docker_build.sh
- Mesos ReviewBot
On March 2, 2016, 6:21 a.m., Neil Conway wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44251/
> -----------------------------------------------------------
>
> (Updated March 2, 2016, 6:21 a.m.)
>
>
> Review request for mesos and Joris Van Remoortere.
>
>
> Bugs: MESOS-4833
> https://issues.apache.org/jira/browse/MESOS-4833
>
>
> Repository: mesos
>
>
> Description
> -------
>
> When the cluster contains many resources that have either labeled
> reservations or persistent volumes, allocator performance can decrease
> substantially because such metadata prevents `Resource` objects from
> being merged together inside the allocator. As a result, the allocator
> must manipulate `Resources` vectors that consist of many small
> individual `Resource` values; since many `Resources` operations take
> linear-time in the number of `Resource` values they contain, this can
> cause very significant slowdowns.
>
> As a short-term solution, this commit strips dynamic reservation and
> persistent volume information from the `Resources` objects used
> internally by the allocator, because they are not needed when
> aggregating resource quantities together.
>
> A long-term solution for this problem will be addressed as work on
> refactoring the allocator more generally.
>
>
> Diffs
> -----
>
> src/master/allocator/mesos/hierarchical.cpp 24fa50f62dec10ed43089297473cc386d6ba2f78
> src/master/allocator/sorter/drf/sorter.hpp 46b2a9caf13b028a3aee6c1590679f885be90fd6
> src/master/allocator/sorter/drf/sorter.cpp 9e863dd0ca5e2f2f0d517cb833687b757bed2c52
> src/master/allocator/sorter/sorter.hpp ba91a38e47065718af87c9b3b7c5b74d25a258df
>
> Diff: https://reviews.apache.org/r/44251/diff/
>
>
> Testing
> -------
>
> make check
>
> Perf:
>
> ```
> [ RUN ] HierarchicalAllocator_BENCHMARK_Test.ResourceLabels
> Using 2000 slaves and 200 frameworks
> round 0 allocate took 2.458462secs to make 200 offers
> round 1 allocate took 2.427941secs to make 200 offers
> round 2 allocate took 2.460724secs to make 200 offers
> round 3 allocate took 2.443408secs to make 200 offers
> round 4 allocate took 2.464784secs to make 200 offers
> round 5 allocate took 2.501429secs to make 200 offers
> round 6 allocate took 2.468777secs to make 200 offers
> round 7 allocate took 2.482268secs to make 200 offers
> round 8 allocate took 2.479014secs to make 200 offers
> round 9 allocate took 2.529951secs to make 200 offers
> round 10 allocate took 2.460059secs to make 200 offers
> ```
>
> Performance of `DeclineOffers` without labels is about ~2.1 seconds.
>
>
> Thanks,
>
> Neil Conway
>
>
Re: Review Request 44251: Improved allocator perf for labeled
reservations and volumes.
Posted by Joris Van Remoortere <jo...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/44251/#review121757
-----------------------------------------------------------
Ship it!
Ship It!
- Joris Van Remoortere
On March 2, 2016, 7:17 p.m., Neil Conway wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44251/
> -----------------------------------------------------------
>
> (Updated March 2, 2016, 7:17 p.m.)
>
>
> Review request for mesos and Joris Van Remoortere.
>
>
> Bugs: MESOS-4833
> https://issues.apache.org/jira/browse/MESOS-4833
>
>
> Repository: mesos
>
>
> Description
> -------
>
> When the cluster contains many resources that have either labeled
> reservations or persistent volumes, allocator performance can decrease
> substantially because such metadata prevents `Resource` objects from
> being merged together inside the allocator. As a result, the allocator
> must manipulate `Resources` vectors that consist of many small
> individual `Resource` values; since many `Resources` operations take
> linear-time in the number of `Resource` values they contain, this can
> cause very significant slowdowns.
>
> As a short-term solution, this commit strips dynamic reservation and
> persistent volume information from the `Resources` objects used
> internally by the allocator, because they are not needed when
> aggregating resource quantities together.
>
> A long-term solution for this problem will be addressed as work on
> refactoring the allocator more generally.
>
>
> Diffs
> -----
>
> src/master/allocator/mesos/hierarchical.cpp 24fa50f62dec10ed43089297473cc386d6ba2f78
> src/master/allocator/sorter/drf/sorter.hpp 46b2a9caf13b028a3aee6c1590679f885be90fd6
> src/master/allocator/sorter/drf/sorter.cpp 9e863dd0ca5e2f2f0d517cb833687b757bed2c52
> src/master/allocator/sorter/sorter.hpp ba91a38e47065718af87c9b3b7c5b74d25a258df
>
> Diff: https://reviews.apache.org/r/44251/diff/
>
>
> Testing
> -------
>
> make check
>
> Perf:
>
> ```
> [ RUN ] HierarchicalAllocator_BENCHMARK_Test.ResourceLabels
> Using 2000 slaves and 200 frameworks
> round 0 allocate took 2.458462secs to make 200 offers
> round 1 allocate took 2.427941secs to make 200 offers
> round 2 allocate took 2.460724secs to make 200 offers
> round 3 allocate took 2.443408secs to make 200 offers
> round 4 allocate took 2.464784secs to make 200 offers
> round 5 allocate took 2.501429secs to make 200 offers
> round 6 allocate took 2.468777secs to make 200 offers
> round 7 allocate took 2.482268secs to make 200 offers
> round 8 allocate took 2.479014secs to make 200 offers
> round 9 allocate took 2.529951secs to make 200 offers
> round 10 allocate took 2.460059secs to make 200 offers
> ```
>
> Performance of `DeclineOffers` without labels is about ~2.1 seconds.
>
>
> Thanks,
>
> Neil Conway
>
>
Re: Review Request 44251: Improved allocator perf for labeled
reservations and volumes.
Posted by Neil Conway <ne...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/44251/
-----------------------------------------------------------
(Updated March 2, 2016, 7:17 p.m.)
Review request for mesos and Joris Van Remoortere.
Changes
-------
Tweak variable name.
Bugs: MESOS-4833
https://issues.apache.org/jira/browse/MESOS-4833
Repository: mesos
Description
-------
When the cluster contains many resources that have either labeled
reservations or persistent volumes, allocator performance can decrease
substantially because such metadata prevents `Resource` objects from
being merged together inside the allocator. As a result, the allocator
must manipulate `Resources` vectors that consist of many small
individual `Resource` values; since many `Resources` operations take
linear-time in the number of `Resource` values they contain, this can
cause very significant slowdowns.
As a short-term solution, this commit strips dynamic reservation and
persistent volume information from the `Resources` objects used
internally by the allocator, because they are not needed when
aggregating resource quantities together.
A long-term solution for this problem will be addressed as work on
refactoring the allocator more generally.
Diffs (updated)
-----
src/master/allocator/mesos/hierarchical.cpp 24fa50f62dec10ed43089297473cc386d6ba2f78
src/master/allocator/sorter/drf/sorter.hpp 46b2a9caf13b028a3aee6c1590679f885be90fd6
src/master/allocator/sorter/drf/sorter.cpp 9e863dd0ca5e2f2f0d517cb833687b757bed2c52
src/master/allocator/sorter/sorter.hpp ba91a38e47065718af87c9b3b7c5b74d25a258df
Diff: https://reviews.apache.org/r/44251/diff/
Testing
-------
make check
Perf:
```
[ RUN ] HierarchicalAllocator_BENCHMARK_Test.ResourceLabels
Using 2000 slaves and 200 frameworks
round 0 allocate took 2.458462secs to make 200 offers
round 1 allocate took 2.427941secs to make 200 offers
round 2 allocate took 2.460724secs to make 200 offers
round 3 allocate took 2.443408secs to make 200 offers
round 4 allocate took 2.464784secs to make 200 offers
round 5 allocate took 2.501429secs to make 200 offers
round 6 allocate took 2.468777secs to make 200 offers
round 7 allocate took 2.482268secs to make 200 offers
round 8 allocate took 2.479014secs to make 200 offers
round 9 allocate took 2.529951secs to make 200 offers
round 10 allocate took 2.460059secs to make 200 offers
```
Performance of `DeclineOffers` without labels is about ~2.1 seconds.
Thanks,
Neil Conway
Re: Review Request 44251: Improved allocator perf for labeled
reservations and volumes.
Posted by Neil Conway <ne...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/44251/
-----------------------------------------------------------
(Updated March 2, 2016, 7:15 p.m.)
Review request for mesos and Joris Van Remoortere.
Changes
-------
Tweak variable name per Guangya.
Bugs: MESOS-4833
https://issues.apache.org/jira/browse/MESOS-4833
Repository: mesos
Description
-------
When the cluster contains many resources that have either labeled
reservations or persistent volumes, allocator performance can decrease
substantially because such metadata prevents `Resource` objects from
being merged together inside the allocator. As a result, the allocator
must manipulate `Resources` vectors that consist of many small
individual `Resource` values; since many `Resources` operations take
linear-time in the number of `Resource` values they contain, this can
cause very significant slowdowns.
As a short-term solution, this commit strips dynamic reservation and
persistent volume information from the `Resources` objects used
internally by the allocator, because they are not needed when
aggregating resource quantities together.
A long-term solution for this problem will be addressed as work on
refactoring the allocator more generally.
Diffs (updated)
-----
src/master/allocator/mesos/hierarchical.cpp 24fa50f62dec10ed43089297473cc386d6ba2f78
src/master/allocator/sorter/drf/sorter.hpp 46b2a9caf13b028a3aee6c1590679f885be90fd6
src/master/allocator/sorter/drf/sorter.cpp 9e863dd0ca5e2f2f0d517cb833687b757bed2c52
src/master/allocator/sorter/sorter.hpp ba91a38e47065718af87c9b3b7c5b74d25a258df
Diff: https://reviews.apache.org/r/44251/diff/
Testing
-------
make check
Perf:
```
[ RUN ] HierarchicalAllocator_BENCHMARK_Test.ResourceLabels
Using 2000 slaves and 200 frameworks
round 0 allocate took 2.458462secs to make 200 offers
round 1 allocate took 2.427941secs to make 200 offers
round 2 allocate took 2.460724secs to make 200 offers
round 3 allocate took 2.443408secs to make 200 offers
round 4 allocate took 2.464784secs to make 200 offers
round 5 allocate took 2.501429secs to make 200 offers
round 6 allocate took 2.468777secs to make 200 offers
round 7 allocate took 2.482268secs to make 200 offers
round 8 allocate took 2.479014secs to make 200 offers
round 9 allocate took 2.529951secs to make 200 offers
round 10 allocate took 2.460059secs to make 200 offers
```
Performance of `DeclineOffers` without labels is about ~2.1 seconds.
Thanks,
Neil Conway
Re: Review Request 44251: Improved allocator perf for labeled
reservations and volumes.
Posted by Neil Conway <ne...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/44251/
-----------------------------------------------------------
(Updated March 2, 2016, 6:21 a.m.)
Review request for mesos and Joris Van Remoortere.
Changes
-------
Address code review comments.
Bugs: MESOS-4833
https://issues.apache.org/jira/browse/MESOS-4833
Repository: mesos
Description
-------
When the cluster contains many resources that have either labeled
reservations or persistent volumes, allocator performance can decrease
substantially because such metadata prevents `Resource` objects from
being merged together inside the allocator. As a result, the allocator
must manipulate `Resources` vectors that consist of many small
individual `Resource` values; since many `Resources` operations take
linear-time in the number of `Resource` values they contain, this can
cause very significant slowdowns.
As a short-term solution, this commit strips dynamic reservation and
persistent volume information from the `Resources` objects used
internally by the allocator, because they are not needed when
aggregating resource quantities together.
A long-term solution for this problem will be addressed as work on
refactoring the allocator more generally.
Diffs (updated)
-----
src/master/allocator/mesos/hierarchical.cpp 24fa50f62dec10ed43089297473cc386d6ba2f78
src/master/allocator/sorter/drf/sorter.hpp 46b2a9caf13b028a3aee6c1590679f885be90fd6
src/master/allocator/sorter/drf/sorter.cpp 9e863dd0ca5e2f2f0d517cb833687b757bed2c52
src/master/allocator/sorter/sorter.hpp ba91a38e47065718af87c9b3b7c5b74d25a258df
Diff: https://reviews.apache.org/r/44251/diff/
Testing
-------
make check
Perf:
```
[ RUN ] HierarchicalAllocator_BENCHMARK_Test.ResourceLabels
Using 2000 slaves and 200 frameworks
round 0 allocate took 2.458462secs to make 200 offers
round 1 allocate took 2.427941secs to make 200 offers
round 2 allocate took 2.460724secs to make 200 offers
round 3 allocate took 2.443408secs to make 200 offers
round 4 allocate took 2.464784secs to make 200 offers
round 5 allocate took 2.501429secs to make 200 offers
round 6 allocate took 2.468777secs to make 200 offers
round 7 allocate took 2.482268secs to make 200 offers
round 8 allocate took 2.479014secs to make 200 offers
round 9 allocate took 2.529951secs to make 200 offers
round 10 allocate took 2.460059secs to make 200 offers
```
Performance of `DeclineOffers` without labels is about ~2.1 seconds.
Thanks,
Neil Conway