Undersöka möjligheter till resursbegränsnint, t.ex. för hur mycket minne en
användare maximalt kan få utnyttja. Mest intressant vid deploy/drift.
Investigate the posibility of restricting resources, e.g. how much memory a user
may utilise. This is interesting with respect to deployment/running the system.
This little Bash code is nice:
It's a fork bomb. Running this as root is not recommended, but an ordinary user
should not be able to cause havoc with this command. It seems like ulimit -u
helps out in this case. The important thing is that the ulimit is set low
enough. On TLCOS, the default ulimit -u is 512, which protects against this. On
Gotland, though, the limit is 7168, which might be a bit high.
We're having customers with problems like "If four users are simultaneously
browsing web pages with flash, my machine bogs down".
It would be nice if the Linux kernel had support for limiting the amount of CPU
(or other resources, although my impression is that the CPU usage is the biggest
problem) a single user can consume.
http://www.uwsg.iu.edu/hypermail/linux/kernel/0211.3/0630.html talks about
http://surriel.com/patches/, but there doesn't seem to be any
CPU-resource-related patch there which I can find. The same thread also talks
about http://www.tls-technologies.com/CPU/cpu-intro.html, which is however only
available for Linux 2.4.
http://ckrm.sourceforge.net/ looks rather interesting, and an early version of
it is indeed included in SLES9. It's not part of the standard kernel, though,
and it seems last time they tried to get it into the mainstream kernel, Andrew
Morton wanted more real functionality, not only a framework. See
http://lwn.net/Articles/94573/ also has a summary of the status of CKRM.
Wrapping user sessions in cgroups could solve this.
systemd seems to have a lot of settings for this:
It also suggests that CPU is split equally among slices, and each user (not session) gets its own slice. So a systemd system should hopefully get fair CPU sharing between users by default.
See bug 3667 and bug 7304 which deal with variations on this topic and some of the comments here probably better belong on those bugs.