75 lines
		
	
	
		
			3.0 KiB
		
	
	
	
		
			XML
		
	
	
	
	
	
			
		
		
	
	
			75 lines
		
	
	
		
			3.0 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>
 | ||
| $ 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>
 | ||
| systemd.services.httpd.serviceConfig.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)
 | ||
| and 640 MiB of RAM (including swap):
 | ||
| 
 | ||
| <programlisting>
 | ||
| systemd.services.httpd.serviceConfig.MemoryLimit = "512M";
 | ||
| systemd.services.httpd.serviceConfig.ControlGroupAttribute = [ "memory.memsw.limit_in_bytes 640M" ];
 | ||
| </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> | 
