We have a number of systems where we traditionally set strict overcommit handling , and for some time this has caused us some heartburn . Some years ago I speculated that we might want to use resource controls on user.slice or systemd.slice if they worked , and then recently in a comment here I speculated that this was the way to (relatively) safely limit memory use if it worked.
Well, it does (as far as I can tell, without deep testing). If you want to limit how much of the system's memory people who log in can use so that system services don't explode, you can set
MemoryMin=
on system.slice to guarantee some amount of memory to it and all things under it. Alternately, you can set
MemoryMax=
on user.slice, collectively limiting all user sessions to that amount of memory. In either case my view is that you might want to set
MemorySwapMax=
on user.slice so that user sessions don't spend all of their time swapping. Which one you set things on depends on which is easier and you trust more; my inclination is MemoryMax, although that means you need to dynamically size it depending on this machine's total memory.
(If you want to limit user memory use you'll need to make sure that things like user cron jobs are forced into user sessions , rather than running under cron.service in system.slice.)
Of course this is what you should expect, given systemd's documentation and the kernel documentation . On the other hand, the Linux kernel cgroup and memory system is sufficiently opaque and ever changing that I feel the need to verify that things actually do work (in our environment) as I expect them to. Sometimes there are surprises, or settings that nominally work but don't really affect things the way I expect.
This does raise the question of how much memory you want to reserve for the system. It would be nice if you could use systemd-cgtop to see how much memory your system.slice is currently using, but unfortunately the number it will show is potentially misleadingly high. This is because the memory attributed to any cgroup includes (much) more than program RAM usage . For example, on our it seems typical for system.slice to be using under a gigabyte of 'user' RAM but also several gigabytes of filesystem cache and other kernel memory. You probably want to allow for some of that in what memory you reserve for system.slice, but maybe not all of the current usage.
(You can get the current version of the 'memdu' program I use as memdu.py .)