Unless I'm mistaken, at some point in LXC, there was the ability to set a limit to amount of swap exposed to a container as exampled below. If that is still available, is it possible to expose that to LXD as well, with a configuration that either specifies amount of swap, or as I believe LXC did it, mem+swap.
# Memory limits
lxc.cgroup.memory.limit_in_bytes = 2G
lxc.cgroup.memory.memsw.limit_in_bytes = 4G
Thank you
James
Those knobs are still directly available, yes. Though the way they work can be somewhat confusing (and somehow changes reasonably often) so we've so far decided not to expose them directly, only allowing to enable or disable the use of swap.
So in your case, I'd say just use the "raw.lxc" config key to directly set those keys, in the case above:
printf "lxc.cgroup.memory.limit_in_bytes = 2G\nlxc.cgroup.memory.memsw.limit_in_bytes = 4G" | lxc config set CONTAINER raw.lxc -
Followed by a restart of the container should do what you want. You probably should unset any limits.memory config keys you have though.
Thanks, somehow my brain never quite registered that everything from lxc could still be mapped through raw. I had been using it a lot for lxc.id_map, but guess never made the jump. Perhaps, a bit more to the documentation, to call out that feature, as it can do so much, maybe some additional examples like you just gave, in addition to the ones that are there for the id_map.
On a side note, why would you not limit the memory? While I am running 1/4 TB of ram standard, I do have a couple of "low ram" containers, but sadly run things like java eap(my CA/RA), that I do not trust, that if they run a mock, I would rather have die, then suck up all the memory that is needed by things like databases and webservers that are more critical for production.
Well, it's not exactly a feature we like to call out as it can interfere with the keys that LXD sets itself and cause some situations that are really annoying to debug :)
We do look at what people use raw.lxc for an where it makes sense, implement a nice high level feature in LXD instead. That's what happened with lxc.id_map which now turned into security.idmap.isolated, security.idmap.size and raw.idmap.
My comment about unsetting limits.memory keys was about avoiding a conflict between what LXD sets internally when you have "limits.memory" set and what you're going to apply through "raw.lxc".
There's nothing wrong with setting memory limits, just don't set them through both "limits.memory" and "raw.lxc" at the same time :)
Closing this issue as there isn't any bug/feature work for us to do immediately on this.
If anyone else is using raw.lxc for swap limits, please comment in this issue so we can get an idea of how common this is and whether we should spend time figuring out how to sanely expose that through limits.memory.
For those who want to use it, don't forget on debian/ubuntu the following:
GRUB_CMDLINE_LINUX_DEFAULT="quiet cgroup_enable=memory swapaccount=1"
Not sure what may be required on other platforms
@stgraber I am also using raw.lxc for applying swap limits directly. It would be nice to have an option in the LXD tool chain to set this.
Most helpful comment
@stgraber I am also using raw.lxc for applying swap limits directly. It would be nice to have an option in the LXD tool chain to set this.