> On June 4, 2014, 4:37 p.m., Vinod Kone wrote:
> > src/slave/slave.cpp, line 2304
> > <https://reviews.apache.org/r/22251/diff/1/?file=603699#file603699line2304>
> >
> >     pull these out into constants.
> >     
> >     DEFAULT_EXECUTOR_CPUS
> >     DEFAULT_EXECUTOR_MEM
> >     
> >     Also these values seem to be too high? what is the minimum value 
> > allowed by cgroups?

Technically, zero is valid for both but it needs to be something sensible to 
avoid starving or OOMing the executor. I looked at a command executor running 
in a memory cgroup and its memory usage was ~ 4 MB. 

The numbers don't really mean much because the slave doesn't account for them; 
they are upper bounds to ensure a borked executor doesn't overtake the host.


- Ian


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22251/#review44776
-----------------------------------------------------------


On June 4, 2014, 4:36 p.m., Ian Downes wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22251/
> -----------------------------------------------------------
> 
> (Updated June 4, 2014, 4:36 p.m.)
> 
> 
> Review request for mesos, Ben Mahler, Jie Yu, and Vinod Kone.
> 
> 
> Bugs: MESOS-1417
>     https://issues.apache.org/jira/browse/MESOS-1417
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Give the command executor some cpu and memory.
> 
> This is necessary because after a terminal task status update the slave 
> updates the container's resources, which would be zero if the executor didn't 
> have its own resources.
> 
> This does lead to a small overcommit but the command executor is only 
> (mainly?) used for tests.
> 
> 
> Diffs
> -----
> 
>   src/slave/slave.cpp 643c0882a4bab1b612b3fb6fd1004e09edf5f368 
> 
> Diff: https://reviews.apache.org/r/22251/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Ian Downes
> 
>

Reply via email to