about summary refs log tree commit diff
path: root/nixpkgs/nixos/doc/manual/administration/control-groups.xml
diff options
context:
space:
mode:
Diffstat (limited to 'nixpkgs/nixos/doc/manual/administration/control-groups.xml')
-rw-r--r--nixpkgs/nixos/doc/manual/administration/control-groups.xml65
1 files changed, 0 insertions, 65 deletions
diff --git a/nixpkgs/nixos/doc/manual/administration/control-groups.xml b/nixpkgs/nixos/doc/manual/administration/control-groups.xml
deleted file mode 100644
index 16d03cc0d1ab..000000000000
--- a/nixpkgs/nixos/doc/manual/administration/control-groups.xml
+++ /dev/null
@@ -1,65 +0,0 @@
-<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>