8ac5e011d6
GitOrigin-RevId: 2c3273caa153ee8eb5786bc8141b85b859e7efd7
65 lines
3 KiB
XML
65 lines
3 KiB
XML
<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>
|
||
<prompt>$ </prompt>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>
|
||
<link linkend="opt-systemd.services._name_.serviceConfig">systemd.services.httpd.serviceConfig</link>.CPUShares = 512;
|
||
</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 <literal>httpd.service</literal> to 512 MiB of RAM
|
||
(excluding swap):
|
||
<programlisting>
|
||
<link linkend="opt-systemd.services._name_.serviceConfig">systemd.services.httpd.serviceConfig</link>.MemoryLimit = "512M";
|
||
</programlisting>
|
||
</para>
|
||
<para>
|
||
The command <command>systemd-cgtop</command> shows a continuously updated
|
||
list of all cgroups with their CPU and memory usage.
|
||
</para>
|
||
</chapter>
|