From e63f523491e0bb757f66b91d5efb2d709612f4bd Mon Sep 17 00:00:00 2001 From: Bobby Rong Date: Sat, 3 Jul 2021 14:33:50 +0800 Subject: [PATCH] nixos: nixos/doc/manual/administration/control-groups.xml to CommonMark --- .../administration/control-groups.chapter.md | 59 ++++++++++++++++ .../manual/administration/control-groups.xml | 65 ------------------ nixos/doc/manual/administration/running.xml | 2 +- .../administration/control-groups.chapter.xml | 67 +++++++++++++++++++ 4 files changed, 127 insertions(+), 66 deletions(-) create mode 100644 nixos/doc/manual/administration/control-groups.chapter.md delete mode 100644 nixos/doc/manual/administration/control-groups.xml create mode 100644 nixos/doc/manual/from_md/administration/control-groups.chapter.xml diff --git a/nixos/doc/manual/administration/control-groups.chapter.md b/nixos/doc/manual/administration/control-groups.chapter.md new file mode 100644 index 00000000000..abe8dd80b5a --- /dev/null +++ b/nixos/doc/manual/administration/control-groups.chapter.md @@ -0,0 +1,59 @@ +# Control Groups {#sec-cgroups} + +To keep track of the processes in a running system, systemd uses +*control groups* (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. + +The command `systemd-cgls` lists all control groups in the `systemd` +hierarchy, which is what systemd uses to keep track of the processes +belonging to each service or user session: + +```ShellSession +$ 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 + └─ ... +``` + +Similarly, `systemd-cgls cpu` 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 `httpd.service` cgroup cannot starve the CPU +for one process in the `postgresql.service` 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 +`configuration.nix`: + +```nix +systemd.services.httpd.serviceConfig.CPUShares = 512; +``` + +By default, every cgroup has 1024 CPU shares, so this will halve the CPU +allocation of the `httpd.service` cgroup. + +There also is a `memory` 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 `configuration.nix`; for instance, to limit +`httpd.service` to 512 MiB of RAM (excluding swap): + +```nix +systemd.services.httpd.serviceConfig.MemoryLimit = "512M"; +``` + +The command `systemd-cgtop` shows a continuously updated list of all +cgroups with their CPU and memory usage. diff --git a/nixos/doc/manual/administration/control-groups.xml b/nixos/doc/manual/administration/control-groups.xml deleted file mode 100644 index 16d03cc0d1a..00000000000 --- a/nixos/doc/manual/administration/control-groups.xml +++ /dev/null @@ -1,65 +0,0 @@ - - Control Groups - - To keep track of the processes in a running system, systemd uses - control groups (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. - - - The command systemd-cgls lists all control groups in the - systemd hierarchy, which is what systemd uses to keep - track of the processes belonging to each service or user session: - -$ 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 - └─ ... - - Similarly, systemd-cgls cpu 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 httpd.service cgroup cannot - starve the CPU for one process in the postgresql.service - 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 configuration.nix: - -systemd.services.httpd.serviceConfig.CPUShares = 512; - - By default, every cgroup has 1024 CPU shares, so this will halve the CPU - allocation of the httpd.service cgroup. - - - There also is a memory 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 configuration.nix; for - instance, to limit httpd.service to 512 MiB of RAM - (excluding swap): - -systemd.services.httpd.serviceConfig.MemoryLimit = "512M"; - - - - The command systemd-cgtop shows a continuously updated - list of all cgroups with their CPU and memory usage. - - diff --git a/nixos/doc/manual/administration/running.xml b/nixos/doc/manual/administration/running.xml index 8a5e25e717f..43642b659a8 100644 --- a/nixos/doc/manual/administration/running.xml +++ b/nixos/doc/manual/administration/running.xml @@ -13,7 +13,7 @@ - + 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 @@ + + Control Groups + + To keep track of the processes in a running system, systemd uses + control groups (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. + + + The command systemd-cgls lists all control groups + in the systemd hierarchy, which is what systemd + uses to keep track of the processes belonging to each service or + user session: + + +$ 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 + └─ ... + + + Similarly, systemd-cgls cpu 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 httpd.service cgroup cannot starve the CPU + for one process in the postgresql.service 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 configuration.nix: + + +systemd.services.httpd.serviceConfig.CPUShares = 512; + + + By default, every cgroup has 1024 CPU shares, so this will halve the + CPU allocation of the httpd.service cgroup. + + + There also is a memory 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 + configuration.nix; for instance, to limit + httpd.service to 512 MiB of RAM (excluding swap): + + +systemd.services.httpd.serviceConfig.MemoryLimit = "512M"; + + + The command systemd-cgtop shows a continuously + updated list of all cgroups with their CPU and memory usage. + +