Thanks - that makes sense. Have stopped running with the
--cgroups_limit_swap option
and confirm the limit_in_bytes is now set.
Not ideal as we'll start eating swap now - but hopefully should be
able to get an upgrade before
that becomes a real problem.
On 28 April 2015 at 18:59, Ian Downes wro
Ahh, my bad I should have looked more closely at your version. This was a
bug that was introduced when the memsw functionality came in and then fixed
in 0.22.0.
See:
https://issues.apache.org/jira/browse/MESOS-2128
commit 24cb10a2d68
I suggest upgrading to >= 0.22.0 or, if that's not desirable, d
You may very well be right, but I'd like to keep this specific thread
focussed on figuring
out why the expected/implemented behaviour isn't happening in my case
if that's ok.
On 28 April 2015 at 19:26, CCAAT wrote:
> I really hate to be the 'old fashion computer scientist' in this group,
> but,
That's what led me into reading the code - neither mem.limit_in_bytes
or mem.memsw.limit_in_bytes
are ever set down from the (insanely high) defaults. I know that
second conditional is false, so the first
must be too, right?
It's likely I'm reading the wrong branch; we're running the 0.21.0
releas
On 04/28/2015 11:54 AM, Dick Davies wrote:
Thanks Ian.
Digging around the cgroup there are 3 processes in there;
* the mesos-executor
* the shell script marathon starts the app with
* the actual command to run the task ( a perl app in this case)
We've been having discussions about various asp
The control flow in the Mesos containerizer to launch a container is:
1. Call prepare() on each isolator
2. Then fork the executor
3. Then isolate(executor_pid) on each isolator
The last part of (1) will also call Isolator::update() to set the initial
memory limits (see line 288). This is done *b
Thanks Ian.
Digging around the cgroup there are 3 processes in there;
* the mesos-executor
* the shell script marathon starts the app with
* the actual command to run the task ( a perl app in this case)
The line of code you mention is never run in our case, because it's
wrapped in the conditiona
The line of code you cite is so the hard limit is not decreased on a
running container because we can't (easily) reclaim anonymous memory from
running processes. See the comment above the code.
The info->pid.isNone() is for when cgroup is being configured (see the
update() call at the end of MemIs
Been banging my head against this for a while now.
mesos 0.21.0 , marathon 0.7.5, centos 6 servers.
When I enable cgroups (flags are : --cgroups_limit_swap
--isolation=cgroups/cpu,groups/mem ) the memory limits I'm setting
are reflected in memory.soft_limit_in_bytes but not in
memory.limit_in_b
9 matches
Mail list logo
