----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/25035/#review53362 -----------------------------------------------------------
Minor nits and we will get this committed. Thanks for your patience Martin. CHANGELOG <https://reviews.apache.org/r/25035/#comment93059> Thinking a bit more about this and talking to others. Adding deprecations in a bug fix release is bit weird. 2 options. 1) We can land this feature in 0.21.0 and not 0.20.1. That way we will do deprecation warning in 0.21.0 and disallow cpu/mem only executors in 0.22.0. This is the most straightforward. 2) Land this in 0.20.1, but the deprecation warning, in changelog (and ResourceUsageChecker?), happens in 0.21.0. The disallowing hapens in 0.22.0. This is bit weird but not too bad if you absolutely need this in 0.20.1. Considering 0.21.0 would happen in a month or so, I prefer #1. Does that work for you? src/master/master.cpp <https://reviews.apache.org/r/25035/#comment92992> also log the cpu resources used by the executor for easier debugging. e.g., LOG(WARNING) << "Executor " << task.executor().executor_id() << " for task " << task.task_id() << " uses less CPUs (" << cpus.isSome() ? cpus.get() : "none" << ") than the minimum required (" << MIN_CPUS << "). Please update........" src/master/master.cpp <https://reviews.apache.org/r/25035/#comment92993> ditto. log requested memory. src/tests/allocator_tests.cpp <https://reviews.apache.org/r/25035/#comment92991> 2 blank lines. src/tests/allocator_tests.cpp <https://reviews.apache.org/r/25035/#comment92990> 2 blank lines. - Vinod Kone On Sept. 13, 2014, 7:10 p.m., Martin Weindel wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/25035/ > ----------------------------------------------------------- > > (Updated Sept. 13, 2014, 7:10 p.m.) > > > Review request for mesos and Vinod Kone. > > > Bugs: MESOS-1688 > https://issues.apache.org/jira/browse/MESOS-1688 > > > Repository: mesos-git > > > Description > ------- > > As already explained in JIRA MESOS-1688, there are schedulers allocating > memory only for the executor and not for tasks. For tasks only CPU resources > are allocated in this case. > Such a scheduler does not get offered any idle CPUs if the slave has nearly > used up all memory. > This can easily lead to a dead lock (in the application, not in Mesos). > > Simple example: > 1. Scheduler allocates all memory of a slave for an executor > 2. Scheduler launches a task for this executor (allocating 1 CPU) > 3. Task finishes: 1 CPU , 0 MB memory allocatable. > 4. No offers are made, as no memory is left. Scheduler will wait for offers > forever. Dead lock in the application. > > To fix this problem, offers must be made if CPU resources are allocatable > without considering allocatable memory > > > Diffs > ----- > > CHANGELOG a822cc4 > src/common/resources.cpp edf36b1 > src/master/constants.cpp faa1503 > src/master/hierarchical_allocator_process.hpp 34f8cd6 > src/master/master.cpp 18464ba > src/tests/allocator_tests.cpp 774528a > > Diff: https://reviews.apache.org/r/25035/diff/ > > > Testing > ------- > > Deployed patched Mesos 0.19.1 on a small cluster with 3 slaves and tested > running multiple parallel Spark jobs in "fine-grained" mode to saturate > allocatable memory. The jobs run fine now. This load always caused a dead > lock in all Spark jobs within one minute with the unpatched Mesos. > > > Thanks, > > Martin Weindel > >
