linux:system:cgroupsv2
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| linux:system:cgroupsv2 [2022/11/20 11:46] – oscar | linux:system:cgroupsv2 [2022/11/20 15:35] (current) – [Cgroups with systemd] oscar | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Cgroups V2 ====== | ====== Cgroups V2 ====== | ||
| ===== Introduction ===== | ===== Introduction ===== | ||
| - | Cgroup v2 provides a unified control system with enhanced resource management capabilities. Control groups (cgroups), are a Linux kernel feature which allow processes to be organized into hierarchical groups whose usage of various types of resources can then be limited and monitored. | + | Cgroup v2 provides a unified control system with enhanced resource management capabilities. Control groups (cgroups), are a Linux kernel feature which allow processes to be organized into hierarchical groups whose usage of various types of resources can then be limited and monitored. |
| + | |||
| + | * a hierarchy to organize processes | ||
| + | * controllers in the kernel | ||
| ===== Identify cgroup version ===== | ===== Identify cgroup version ===== | ||
| Line 9: | Line 12: | ||
| For cgroup v2, the output is **cgroup2fs**. For cgroup v1, the output is **tmpfs** | For cgroup v2, the output is **cgroup2fs**. For cgroup v1, the output is **tmpfs** | ||
| + | |||
| + | ===== Hierarchy ===== | ||
| + | Current cgroup hierarchy can be seen with **systemctl status** or **systemd-cgls** command. | ||
| + | < | ||
| + | $ systemctl status | ||
| + | |||
| + | ● mylinux | ||
| + | State: running | ||
| + | Jobs: 0 queued | ||
| + | | ||
| + | Since: Wed 2019-12-04 22:16:28 UTC; 1 day 4h ago | ||
| + | | ||
| + | | ||
| + | │ └─user-1000.slice | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | │ └─1 /sbin/init | ||
| + | | ||
| + | | ||
| + | │ └─285 / | ||
| + | | ||
| + | │ └─272 / | ||
| + | | ||
| + | │ └─656 / | ||
| + | | ||
| + | │ └─668 / | ||
| + | | ||
| + | </ | ||
| + | |||
| + | ===== cgroup resource usage ===== | ||
| + | The **systemd-cgtop** command can be used to see the resource usage: | ||
| + | < | ||
| + | $ systemd-cgtop | ||
| + | |||
| + | Control Group Tasks | ||
| + | user.slice | ||
| + | user.slice/ | ||
| + | user.slice/ | ||
| + | system.slice | ||
| + | </ | ||
| ===== Cgroup Filesystem ===== | ===== Cgroup Filesystem ===== | ||
| - | The / | + | The **/ |
| + | - Interface | ||
| + | * cgroup.controllers – This shows the supported cgroup controllers. | ||
| + | * cgroup.procs – contains the list of PIDs of processes. Attaching a process to a subgroup is done by writing its PID into the subgroup' | ||
| + | * cgroup.subtree_control – holds the controllers that are enabled for the immediate subgroups | ||
| + | - Controller-specific files such as cpuset.cpus.effective. | ||
| + | - Directories | ||
| + | * / | ||
| + | * / | ||
| + | * / | ||
| < | < | ||
| root@homeserver:/ | root@homeserver:/ | ||
| Line 57: | Line 124: | ||
| ===== Enabled Controllers ===== | ===== Enabled Controllers ===== | ||
| Check which controller are activated / enabled: | Check which controller are activated / enabled: | ||
| - | # / | + | # cat / |
| | | ||
| cpuset cpu io memory hugetlb pids rdma | cpuset cpu io memory hugetlb pids rdma | ||
| Line 183: | Line 250: | ||
| -rw-r—r--. 1 root root 0 Jun 1 11:45 memory.pressure | -rw-r—r--. 1 root root 0 Jun 1 11:45 memory.pressure | ||
| </ | </ | ||
| + | |||
| + | ===== Find cgroup of a process ===== | ||
| + | The cgroup name of a process can be found in / | ||
| + | < | ||
| + | $ ps | ||
| + | PID TTY TIME CMD | ||
| + | 3282 pts/2 00:00:00 su | ||
| + | 3288 pts/2 00:00:00 bash | ||
| + | 3968 pts/2 00:00:00 ps | ||
| + | |||
| + | $ cat / | ||
| + | 0::/ | ||
| + | </ | ||
| + | |||
| + | ====== Cgroups with systemd ====== | ||
| + | All processes running on the system are child processes of the systemd init process. Systemd provides three unit types that are used for the purpose of resource control: | ||
| + | |||
| + | - **Service** — A process or a group of processes, which systemd started based on a unit configuration file. Services encapsulate the specified processes so that they can be started and stopped as one set. Services are named in the following way: name.service. | ||
| + | - **Scope** — A group of externally created processes. Scopes encapsulate processes that are started and stopped by arbitrary processes through the fork() function and then registered by systemd at runtime. For instance, user sessions, containers, and virtual machines are treated as scopes. Scopes are named as follows: name.scope. | ||
| + | - **Slice** — A group of hierarchically organized units. Slices do not contain processes, they organize a hierarchy in which scopes and services are placed. The actual processes are contained in scopes or in services. In this hierarchical tree, every name of a slice unit corresponds to the path to a location in the hierarchy. The dash (" | ||
| + | |||
| + | Services, scopes, and slices are created manually by the system administrator or dynamically by programs. By default, the operating system defines a number of built-in services that are necessary to run the system. Also, there are four slices created by default: | ||
| + | |||
| + | - **-.slice** — the root slice; | ||
| + | - **system.slice** — the default place for all system services; | ||
| + | - **user.slice** — the default place for all user sessions; | ||
| + | - **machine.slice** — the default place for all virtual machines and Linux containers. | ||
| + | |||
| + | Note that all user sessions are automatically placed in a separated scope unit, as well as virtual machines and container processes. Furthermore, | ||
| + | |||
| + | By default, systemd creates a new cgroup under the system.slice for each service it monitors. | ||
| + | < | ||
| + | └─system.slice | ||
| + | ├─sssd.service | ||
| + | ├─lvm2-lvmetad.service | ||
| + | ├─rsyslog.service | ||
| + | ├─systemd-udevd.service | ||
| + | ├─systemd-logind.service | ||
| + | ├─systemd-journald.service | ||
| + | ├─crond.service | ||
| + | ├─origin-node.service | ||
| + | ├─docker.service | ||
| + | ├─dnsmasq.service | ||
| + | ├─tuned.service | ||
| + | ├─sshd.service | ||
| + | ├─NetworkManager.service | ||
| + | ├─dbus.service | ||
| + | ├─polkit.service | ||
| + | </ | ||
| + | You can change this behavior by editing the systemd service file. There are three options with regard to cgroup management with systemd: | ||
| + | - Editing the service file itself. | ||
| + | - Using drop-in files. | ||
| + | - Using systemctl set-property commands, which are the same as manually editing the files, but systemctl creates the required entries for you. | ||
| + | |||
| + | ===== Editing service files ===== | ||
| + | Let's edit the unit file itself. To do this, add the following line to the .service file: | ||
| + | Slice=my_slice.slice | ||
| + | After this it is no longer attached to the system.slice but under it's own slice: | ||
| + | < | ||
| + | Control group /: | ||
| + | ├─my_beautiful_slice.slice | ||
| + | │ └─cat.service | ||
| + | │ | ||
| + | </ | ||
| + | |||
| + | Note about " | ||
| + | < | ||
| + | Control group /: | ||
| + | ├─my.slice | ||
| + | │ └─my-nested.slice | ||
| + | │ | ||
| + | │ | ||
| + | │ | ||
| + | </ | ||
| + | |||
| + | |||
| + | ===== Using drop-in files ===== | ||
| + | Drop-in files for systemd are fairly trivial to set up. Start by making an appropriate directory based on your service' | ||
| + | |||
| + | # mkdir -p / | ||
| + | |||
| + | These files can be organized any way you like them. They are actioned based on numerical order, so you should name your configuration files something like 10-CPUSettings.conf. All files in this directory should have the file extension .conf and require you to run systemctl daemon-reload every time you adjust one of these files. | ||
| + | |||
| + | I have created two drop-in files to show how you can split out different configurations. The first is 00-slice.conf. As seen below, it sets up the default options for a separate slice for the cat service: | ||
| + | < | ||
| + | [Service] | ||
| + | Slice=AWESOME.slice | ||
| + | MemoryAccounting=yes | ||
| + | CPUAccounting=yes | ||
| + | </ | ||
| + | |||
| + | ===== Using systemctl set-property ===== | ||
| + | The last method that can be used to configure cgroups is the systemctl set-property command, which places the files in / | ||
| + | |||
linux/system/cgroupsv2.1668944812.txt.gz · Last modified: by oscar