2014-08-24 17:18:18 +00:00
|
|
|
|
<chapter xmlns="http://docbook.org/ns/docbook"
|
|
|
|
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
|
|
|
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
|
|
|
|
version="5.0"
|
|
|
|
|
|
xml:id="sec-cgroups">
|
|
|
|
|
|
|
|
|
|
|
|
<title>Control Groups</title>
|
|
|
|
|
|
|
|
|
|
|
|
<para>To keep track of the processes in a running system, systemd uses
|
|
|
|
|
|
<emphasis>control groups</emphasis> (cgroups). A control group is a
|
|
|
|
|
|
set of processes used to allocate resources such as CPU, memory or I/O
|
|
|
|
|
|
bandwidth. There can be multiple control group hierarchies, allowing
|
|
|
|
|
|
each kind of resource to be managed independently.</para>
|
|
|
|
|
|
|
|
|
|
|
|
<para>The command <command>systemd-cgls</command> lists all control
|
|
|
|
|
|
groups in the <literal>systemd</literal> hierarchy, which is what
|
|
|
|
|
|
systemd uses to keep track of the processes belonging to each service
|
|
|
|
|
|
or user session:
|
|
|
|
|
|
|
|
|
|
|
|
<screen>
|
|
|
|
|
|
$ systemd-cgls
|
|
|
|
|
|
├─user
|
|
|
|
|
|
│ └─eelco
|
|
|
|
|
|
│ └─c1
|
|
|
|
|
|
│ ├─ 2567 -:0
|
|
|
|
|
|
│ ├─ 2682 kdeinit4: kdeinit4 Running...
|
|
|
|
|
|
│ ├─ <replaceable>...</replaceable>
|
|
|
|
|
|
│ └─10851 sh -c less -R
|
|
|
|
|
|
└─system
|
|
|
|
|
|
├─httpd.service
|
|
|
|
|
|
│ ├─2444 httpd -f /nix/store/3pyacby5cpr55a03qwbnndizpciwq161-httpd.conf -DNO_DETACH
|
|
|
|
|
|
│ └─<replaceable>...</replaceable>
|
|
|
|
|
|
├─dhcpcd.service
|
|
|
|
|
|
│ └─2376 dhcpcd --config /nix/store/f8dif8dsi2yaa70n03xir8r653776ka6-dhcpcd.conf
|
|
|
|
|
|
└─ <replaceable>...</replaceable>
|
|
|
|
|
|
</screen>
|
|
|
|
|
|
|
|
|
|
|
|
Similarly, <command>systemd-cgls cpu</command> shows the cgroups in
|
|
|
|
|
|
the CPU hierarchy, which allows per-cgroup CPU scheduling priorities.
|
|
|
|
|
|
By default, every systemd service gets its own CPU cgroup, while all
|
|
|
|
|
|
user sessions are in the top-level CPU cgroup. This ensures, for
|
|
|
|
|
|
instance, that a thousand run-away processes in the
|
|
|
|
|
|
<literal>httpd.service</literal> cgroup cannot starve the CPU for one
|
|
|
|
|
|
process in the <literal>postgresql.service</literal> cgroup. (By
|
|
|
|
|
|
contrast, it they were in the same cgroup, then the PostgreSQL process
|
|
|
|
|
|
would get 1/1001 of the cgroup’s CPU time.) You can limit a service’s
|
|
|
|
|
|
CPU share in <filename>configuration.nix</filename>:
|
|
|
|
|
|
|
|
|
|
|
|
<programlisting>
|
2018-04-05 08:43:56 +00:00
|
|
|
|
<link linkend="opt-systemd.services._name_.serviceConfig">systemd.services.httpd.serviceConfig</link>.CPUShares = 512;
|
2014-08-24 17:18:18 +00:00
|
|
|
|
</programlisting>
|
|
|
|
|
|
|
|
|
|
|
|
By default, every cgroup has 1024 CPU shares, so this will halve the
|
|
|
|
|
|
CPU allocation of the <literal>httpd.service</literal> cgroup.</para>
|
|
|
|
|
|
|
|
|
|
|
|
<para>There also is a <literal>memory</literal> hierarchy that
|
|
|
|
|
|
controls memory allocation limits; by default, all processes are in
|
|
|
|
|
|
the top-level cgroup, so any service or session can exhaust all
|
|
|
|
|
|
available memory. Per-cgroup memory limits can be specified in
|
|
|
|
|
|
<filename>configuration.nix</filename>; for instance, to limit
|
2014-12-30 17:32:05 +00:00
|
|
|
|
<literal>httpd.service</literal> to 512 MiB of RAM (excluding swap):
|
2014-08-24 17:18:18 +00:00
|
|
|
|
|
|
|
|
|
|
<programlisting>
|
2018-04-05 08:43:56 +00:00
|
|
|
|
<link linkend="opt-systemd.services._name_.serviceConfig">systemd.services.httpd.serviceConfig</link>.MemoryLimit = "512M";
|
2014-08-24 17:18:18 +00:00
|
|
|
|
</programlisting>
|
|
|
|
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
|
|
<para>The command <command>systemd-cgtop</command> shows a
|
|
|
|
|
|
continuously updated list of all cgroups with their CPU and memory
|
|
|
|
|
|
usage.</para>
|
|
|
|
|
|
|
2014-12-30 17:32:05 +00:00
|
|
|
|
</chapter>
|
