diff options
Diffstat (limited to 'nixos/doc/manual/administration/control-groups.xml')
| -rw-r--r-- | nixos/doc/manual/administration/control-groups.xml | 33 |
1 files changed, 6 insertions, 27 deletions
diff --git a/nixos/doc/manual/administration/control-groups.xml b/nixos/doc/manual/administration/control-groups.xml index 16d03cc0d1ab..d6ae89da30c4 100644 --- a/nixos/doc/manual/administration/control-groups.xml +++ b/nixos/doc/manual/administration/control-groups.xml @@ -5,16 +5,10 @@ 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. + 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: + 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 @@ -32,34 +26,19 @@ │ └─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>: + 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. + 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): + 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. + The command <command>systemd-cgtop</command> shows a continuously updated list of all cgroups with their CPU and memory usage. </para> </chapter> |