1 files changed, 67 insertions, 0 deletions
diff --git a/nixos/doc/manual/from_md/administration/control-groups.chapter.xml b/nixos/doc/manual/from_md/administration/control-groups.chapter.xml
new file mode 100644
index 00000000000..8dab2c9d44b
--- /dev/null
+++ b/nixos/doc/manual/from_md/administration/control-groups.chapter.xml
@@ -0,0 +1,67 @@
+<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" 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 <literal>systemd-cgls</literal> 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:
+  </para>
+  <programlisting>
+$ systemd-cgls
+├─user
+│ └─eelco
+│   └─c1
+│     ├─ 2567 -:0
+│     ├─ 2682 kdeinit4: kdeinit4 Running...
+│     ├─ ...
+│     └─10851 sh -c less -R
+└─system
+  ├─httpd.service
+  │ ├─2444 httpd -f /nix/store/3pyacby5cpr55a03qwbnndizpciwq161-httpd.conf -DNO_DETACH
+  │ └─...
+  ├─dhcpcd.service
+  │ └─2376 dhcpcd --config /nix/store/f8dif8dsi2yaa70n03xir8r653776ka6-dhcpcd.conf
+  └─ ...
+</programlisting>
+  <para>
+    Similarly, <literal>systemd-cgls cpu</literal> 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 <literal>configuration.nix</literal>:
+  </para>
+  <programlisting language="bash">
+systemd.services.httpd.serviceConfig.CPUShares = 512;
+</programlisting>
+  <para>
+    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
+    <literal>configuration.nix</literal>; for instance, to limit
+    <literal>httpd.service</literal> to 512 MiB of RAM (excluding swap):
+  </para>
+  <programlisting language="bash">
+systemd.services.httpd.serviceConfig.MemoryLimit = &quot;512M&quot;;
+</programlisting>
+  <para>
+    The command <literal>systemd-cgtop</literal> shows a continuously
+    updated list of all cgroups with their CPU and memory usage.
+  </para>
+</chapter>