[systemd-devel] Limiting resources

[Lennart Poettering]

On Tue, 22.02.11 12:33, Cristian Patrascu (Cristian.Patrascu at windriver.com) wrote:

> Hi!
> 
> I have some questions regarding the options in a .service that can
> limit the resources of an application specified in ExecStart:
> 1. For memory resource I know there is the "LimitAS" option, but
> what about limiting the CPU, is there any option? For CPU limiting
> I'm interested in specifying the maximum percentage of CPU used or
> maybe the maximum time portion - microseconds or nanoseconds of CPU
> time (either way is good). The goal is not to kill the process, but
> to limit it at maximum X% cpu.

LimitAS is not particularly useful actually, since it just limits
address space, not memory usage. Also, it is per process, which means
that if a process forks it can use double the amount of address space,
and so on. You probably want to use the memory cgroup controller for
this, which is not vulnerable to this problem and actually enforces
limits on memory usage, not just address space.

systemd currently offers no switches to control any of the cgroup
controller settings directly. But we definitely should have that, and it
would be a very natural extension to the current configuration I
believe.

Right now you can use ControlGroup= to configure services into specific
cgroups in specific hierarchies. By default systemd will sort every
service into its own cgroup in the "name=systemd" hierarchy and in the
"cpu" hierarchy. You may list additional hierarchies and their cgroup
paths in that switch to sort things into those. Example:

ControlGroup=memory

(this will copy the cgroup that systemd sorts the service in
from the "name=systemd" hierachy into the "memory" hierachy)

ContolGroup=memory:/waldo

(This will put the service in the cgroup /waldo in the "memory"
hierarchy).

By using this you can then use an external program to set the limits on
the cgroups, such as a shell script that just echos stuff into the various
files in /sys/fs/cgroup/memory/waldo/.

I'd be happy to merge a patch that adds native switches to systemd for
the most relevant cgroup settings of the various hierarchies. For example,
an option like the following would rock:

CPUShares=2048
CPUSetCPUs=2,3

which would implicitly add "cpu" and "cpuset" to the list the user can
otherwise control with ControlGroup=, and then write "2048" resp. "2,3"
to the cpu.shares resp. cpuset.cpus files in the per-daemon cgroups in
those directories.

> 2. If there is such an option, is there a way to read the specified
> cpu limit from the control group hierarchy?

Well, you can always read back things from the cgroup tree.

> 3. Let's say I set "LimitAS", is there a way to read the specified
> memory limit from the control group hierarcy?

Nope. LimitAS and the control group hierarchy are independent, and
LimitAS not really useful anyway.

> 4. How can I set limits in the control group specified in a .service file?
>     Ex.:
>     - in the following control group hierarchy:
> "[...]/cgroup/memory/some_subgroup/" there is a file
> "memory.limit_in_bytes" that contains the maximum memory limit of
> processes running in this subgroup. When processes reach that
> maximum amount of memory, they are killed. So can I set the
> "memory.limit_in_bytes" from a .service configuration file?

No, you can't, but I'd be very happy to change that, i.e. a setting
MemoryLimit= which would implicitly add the "memory" controller to the
list of hierarchies that systemd looks after for a service, and write
the memory.limit_in_bytes file of it.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.