cgroups (and lmctfy) does support limiting memory usage on a per-application basis, as well as a bunch of other resources (ability to run on particular CPUs, access certain network ports, disk/IO, etc).
You can also prevent applications from stomping on each others' files, with a combination of permissions, chroots and mount namespaces.
This is basically a low-level API for a controller daemon. The daemon knows (via a centralized cluster scheduler) what jobs need to be running on the machine, and how much of each kind of resource they're guaranteed and/or are limited to. lmctfy translates those requirements into kernel calls to set up cgroups that implement the required resource limits/guarantees.
While you could use it for hand administration of a box, or even config-file-based administration of a box, you probably wouldn't want to (lxc may well be more appropriate for that).
Comments
cgroups (and lmctfy) does support limiting memory usage on a per-application basis, as well as a bunch of other resources (ability to run on particular CPUs, access certain network ports, disk/IO, etc).
You can also prevent applications from stomping on each others' files, with a combination of permissions, chroots and mount namespaces.
This is basically a low-level API for a controller daemon. The daemon knows (via a centralized cluster scheduler) what jobs need to be running on the machine, and how much of each kind of resource they're guaranteed and/or are limited to. lmctfy translates those requirements into kernel calls to set up cgroups that implement the required resource limits/guarantees.
While you could use it for hand administration of a box, or even config-file-based administration of a box, you probably wouldn't want to (lxc may well be more appropriate for that).