Cgroups and Systemd

Cgroups is a mechanism provided by the Linux kernel, if you do not know Cgroups, please refer to the previous "Linux Cgroups Introduction" First understand Cgroups. When the Linux init system developed to SYSTEMD, Systemd and Cgroups took place (or SYSTEMD provided cgroups use and management interface, SYSTEMD tube more and more ah! )。 This article will briefly describe the relationship between cgroups and SYSTEMD and how to configure and use cgroups through SYSTEMD.

Systemd Dependent cgroups

To understand the relationship between SYSTEMD and cgroups, we need to first distinguish two aspects of cgroups: hierarchy (A) and resource Control (B). First, Cgroups is a way to organize and identify processes in a hierarchical structure, and it is also a way to enforce resource constraints on that hierarchy. We simply refer to the cgroups hierarchy as a, and the Cgrpups's resource control capability is called B.
For Systemd, A is a must, if not A,SYSTEMD will not work very well. b is optional, and if you don't need to control the resources, you can completely remove the B-related compilation options when compiling the Linux kernel.

Systemd Default mounted cgroups system

During the system start-up phase, SYSTEMD will mount the supported controllers (subsystem subsystem) under the default/sys/fs/cgroup/directory:

In addition to the SYSTEMD directory, other directories are the corresponding subsystem.
The/SYS/FS/CGROUP/SYSTEMD directory is a cgroups hierarchy of non-subsystem that SYSTEMD maintains for its own use. This thing is systemd own use, in other words, does not allow other programs to move the contents of this directory. In fact, the/SYS/FS/CGROUP/SYSTEMD directory corresponds to the cgroups hierarchy is systemd used in cgoups feature a.

default level for Cgroup

By binding the Cgroup hierarchy system to the SYSTEMD unit tree, SYSTEMD can move the settings for resource management from the process level to the application level. Therefore, we can use the SYSTEMCTL directive or modify the SYSTEMD unit's configuration file to manage the unit-related resources.

By default, SYSTEMD automatically creates levels of slice, scope, and service unit (slice, scope, and service are SYSTEMD unit types, refer to "First Knowledge systemd") to The Cgroup tree provides a unified hierarchy.

All processes running in the system are child processes of the SYSTEMD init process. In terms of resource management, SYSTEMD provides three unit types:

• Service: A process or set of processes that is initiated by SYSTEMD according to the unit profile. The service encapsulates the specified process so that the process can be started or terminated as a whole.
• Scope: A set of externally created processes. Scope encapsulates a process that is started and terminated by a process through the fork () function and then registered by SYSTEMD at run time. For example: User sessions, containers, and virtual machines are considered scope.
• Slice: A set of units arranged hierarchically. Slice does not contain processes, but it builds a hierarchy and places both scope and service. A real process is contained within a scope or service. In this hierarchical tree, the name of each slice unit corresponds to a path to a position in the hierarchy.

We can view the cgroups hierarchy by Systemd-cgls command:

Service, scope, and slice unit are mapped directly to objects in the Cgroup tree. When these unit is activated, they are mapped directly one by one to the Cgroup path established by the unit name. For example, Cron.service belongs to System.slice and is mapped directly to Cgroup system.slice/cron.service/.
Note that all user sessions, virtual machines, and container processes are automatically placed in a separate scope unit.

By default, four types of slice are created:

• -.slice: Root Slice
• system.slice: Default location for all system service
• user.slice: Default location for all user sessions
• machine.slice: Default location for all virtual machines and Linux containers

Create a temporary cgroup

The settings for resource management can be either transient (temporary) or persistent (permanent). Let's start by describing how to create a temporary cgroup.
You need to use the systemd-run command to create a temporary cgroup that can create and start a temporary service or scope unit and run the program in this unit. The Systemd-run command creates a unit of service type by default, such as we create a service run top command named Toptest:

sudo systemd-run--unit=toptest--slice=test top-b

Then look at the status of the Test.slice:

Creates a Test.slice/toptest.service Cgroup hierarchy relationship. And look at the state of Toptest.service:

The top command is packaged as a service running in the background!

Next, we can limit the resources of Toptest.service by Systemctl command. Before limiting, let's take a look at the Cgroup information for the top process:

$ vim/proc/2850/cgroup           2850 for the top process PID

For example, we limit Toptest.service's cpushares to 600, and the maximum available memory is 550M:

sudo systemctl set-property toptest.service cpushares= memorylimit=500m

Check the Cgroup information for the top process again:

The Toptest.service name appears in both the CPU and memory subsystem. At the same time to see the /sys/fs/cgroup/memory/test.slice and /sys/fs/cgroup/cpu/test.slice directories, both directories have an extra Toptest.service directory. The cpushares=600 memorylimit=500m that we set up are written to the corresponding files in these directories respectively.

The temporary Cgroup feature is that once the contained process is finished, the temporary Cgroup is automatically released. For example, we kill the top process, and then view the/sys/fs/cgroup/memory/test.slice and/sys/fs/cgroup/cpu/test.slice directory, just the Toptest.service The catalog is gone.

modifying Cgroup through configuration files

All Persistent cgroup (persistent cgroup) supervised by SYSTEMD have a unit configuration file in the/usr/lib/systemd/system/directory. For example, our common service type unit configuration file. We can control the resources of the application by setting the unit configuration file, and the persistent cgroup is characterized by the retention of the relevant configuration even if the system restarts. It is important to note that the scope unit cannot be created in this manner. Let's add some CPU and memory-related restrictions for cron.service, edit the/lib/systemd/system/cron.service file:

sudo vim  /lib/systemd/system/cron.service

Add the lines in the red box, reload the configuration file, and restart Cron.service:

sudo systemctl daemon-sudo systemctl restart Cron.service

Now go and see/sys/fs/cgroup/memory/system.slice/cron.service/memory.limit_in_bytes and/sys/fs/cgroup/cpu/system.slice/. Cron.service/cpu.shares file, is not already included in our configured content!

Modify Cgroup with the Systemctl command

In addition to editing the unit's configuration file, you can also modify the Cgroup with the Systemctl set-property command, which is also preserved when the system is restarted. Now let's change Cron.service's cpushares to 700:

sudo systemctl set-property cron.service cpushares=

View the contents of the/sys/fs/cgroup/cpu/system.slice/cron.service/cpu.shares file should be 700, after rebooting the system, the contents of the file or 700.

systemd-cgtop Command

Similar to the top command, the systemd-cgtop command displays real-time resource consumption for cgoups:

With it, we can analyze how the application uses resources.

Summary

SYSTEMD is a powerful init system that even provides convenience for us to use cgorups! SYSTEMD provides an intrinsic mechanism, default settings, and associated manipulation commands to reduce the difficulty of configuring and using Cgroups, and even for new Linux users, it's easy to use cgroups.

reference:
the New Control Group Interfaces
systemd for Administrators, part XVIII
control Groups vs. Control Groups
redhat Cgroups doc
Systemd-cgls
systemd-cgtop