Hm. Actually, further testing seems to suggest that the order is
deterministic, and that they are applied in the order they appear in the
vassal config file, which complies with the principle of least
surprise. Please ignore us.
For anyone else wishing to apply memory cgroup limits, you'll want to do
them in this order:
cgroup-opt = memory.limit_in_bytes=1800M
cgroup-opt = memory.memsw.limit_in_bytes=1800M
but turns out we actually want per-worker limits rather than per-app,
separate question on that to follow.
rgds,
Harry + the PythonAnywhere team.
On 25/05/16 12:19, Harry Percival wrote:
Actually we're seeing conflicting results today -- could the order
that cgroupt-opt lines are applied in actually be random /
nondeterministic? If so, that's going to cause problems with
memory.limit_in_bytes and memory.memsw.limit_in_bytes, which are
sensitive to ordering...
On 23/05/16 18:12, Giles Thomas wrote:
Hi all,
Short question: it looks like cgroup-opt options, when specified in a
uWSGI .ini file, are being applied in the reverse of the order in
which they appear in the .ini file. Is this correct? If so, is it
expected defined behaviour, or is it likely to change?
Background:
We're trying to set the memory.memsw.limit_in_bytes and
memory.limit_in_bytes cgroup options. When we set them from the
command line for non-uWSGI processes, we have to set the
memory.limit_in_bytes option first and then the
memory.memsw.limit_in_bytes option second. Trying to set them the
other way around gives an OS error.
When we set them using cgroup-opt in a uWSGI .ini config file, we
have to specify memory.memsw.limit_in_bytes first and
memory.limit_in_bytes second. If we try to set them the other way
around, the vassal (we're using emperor mode) never starts -- it
keeps getting cursed.
From a quick look at the source code, it looks like the cgroup-opt
options might be being applied in the reverse order to the way
they're specified -- they're being put into a linked list, which is
naturally easier to prepend to than append to, and then applied in
the order they appear in in the linked list.
This is all fine -- we can just specify them in the order that
works. But it would be good to be sure that we're interpreting
what's happening correctly, and to know if we can rely on this
staying the same in the future.
All the best,
Giles
--
Harry Percival
Developer
[email protected]
PythonAnywhere - a fully browser-based Python development and hosting
environment
<http://www.pythonanywhere.com/>
PythonAnywhere LLP
17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79
Registered in England and Wales as company number OC378414.
Registered address: 28 Ely Place, 3rd Floor, London EC1N 6TD, UK
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
