Chapter 26. Configuring resource management by using cgroups-v2 and systemd
The primary function of the systemd suite is service management and supervision. As such systemd ensures that the appropriate services start at the appropriate time and in the correct order during the boot process. When the services are running, they have to run smoothly to use the underlying hardware platform optimally. Therefore, systemd also provides capabilities to define resource management policies and to tune various options, which can improve the performance of the service.
26.1. Prerequisites
- Basic knowledge of the Linux cgroup subsystem.
26.2. Introduction to resource distribution models
For resource management, systemd uses the control groups version 2 (cgroups-v2) interface.
By default, RHEL 8 uses cgroups-v1. Therefore, you must enable cgroups-v2 so that systemd can use the cgroups-v2 interface for resource management. For more information about how to enable cgroups-v2, see Mounting cgroups-v2.
To modify the distribution of system resources, you can apply one or more of the following resource distribution models:
- Weights
A resource is distributed by adding up the weights of all sub-groups and giving each sub-group a fraction of the resource based on its weight as compared to the overall sum of all weights.
For example, if you have 10
cgroups, each with Weight of value 100, the sum is 1000 and eachcgroupreceives one tenth of the resource.Weight is usually used to distribute stateless resources. To adjust the weight of a control group, use the CPUWeight= option.
- Limits
A
cgroupcan consume up to the configured amount of a resource, but you can also overcommit resources. Therefore, the sum of sub-group limits can exceed the limit of the parentcgroup.To adjust the limits of a control group, use the MemoryMax= option.
- Protections
You can set up a protected amount of a resource for a
cgroup. If the resource usage is below the protection boundary, the kernel will try not to penalize thiscgroupin favor of othercgroupsthat compete for the same resource. An overcommit is also possible.To adjust the protected resource amounts for a control group, use the MemoryLow= option.
- Allocations
- Exclusive allocations of a specific amount of a finite resource, such as the real-time budget. An overcommit is possible.
26.3. Allocating CPU resources by using systemd
On a system managed by systemd, each system service is started in its cgroup. By enabling the support for the CPU cgroup controller, the system uses the service-aware distribution of CPU resources instead of the per-process distribution. In the service-aware distribution, each service receives approximately the same amount of CPU time relative to all other services running on the system, regardless of the number of processes that comprise the service.
If a specific service requires more CPU resources, you can grant them by changing the CPU time allocation policy for the service.
Procedure
To set a CPU time allocation policy option when using systemd:
Check the assigned values of the CPU time allocation policy option in the service of your choice:
$ systemctl show --property <CPU time allocation policy option> <service name>Set the required value of the CPU time allocation policy option as a root:
# systemctl set-property <service name> <CPU time allocation policy option>=<value>
The cgroup properties are applied immediately after they are set. Therefore, the service does not need to be restarted.
Verification
To verify whether you successfully changed the required value of the CPU time allocation policy option for your service, enter:
$ systemctl show --property <CPU time allocation policy option> <service name>
26.4. CPU time allocation policy options for systemd
The most frequently used CPU time allocation policy options include:
CPUWeight=Assigns higher priority to a particular service over all other services. You can select a value from the interval 1 – 10,000. The default value is 100.
For example, to give
httpd.servicetwice as much CPU as to all other services, set the value toCPUWeight=200.Note that
CPUWeight=is applied only in cases when available CPU resources are depleted.CPUQuota=Assigns the absolute CPU time quota to a service. The value of this option specifies the maximum percentage of CPU time that a service will receive relative to the total CPU time available, for example
CPUQuota=30%.Note that
CPUQuota=represents the limit value for particular resource distribution models, such as Weights and Limits.For more information about
CPUQuota=, see thesystemd.resource-control(5)man page.
26.5. Allocating memory resources by using systemd
To allocate memory resources by using systemd, use any of the memory configuration options:
-
MemoryMin -
MemoryLow -
MemoryHigh -
MemoryMax -
MemorySwapMax
Procedure
To set a memory allocation configuration option when using systemd:
Check the assigned values of the memory allocation configuration option in the service of your choice.
$ systemctl show --property <memory allocation configuration option> <service name>Set the required value of the memory allocation configuration option as a
root.# systemctl set-property <service name> <memory allocation configuration option>=<value>
The cgroup properties are applied immediately after they are set. Therefore, the service does not need to be restarted.
Verification
To verify whether you have successfully changed the required value of the memory allocation configuration option for your service, enter:
$ systemctl show --property <memory allocation configuration option> <service name>
26.6. Memory allocation configuration options for systemd
You can use the following options when using systemd to configure system memory allocation:
MemoryMin- Hard memory protection. If the memory usage is below the specified limit, the cgroup memory will not be reclaimed.
MemoryLow- Soft memory protection. If the memory usage is below the specified limit, the cgroup memory can be reclaimed only if no memory is reclaimed from unprotected cgroups.
MemoryHigh- Memory throttle limit. If the memory usage goes above the specified limit, the processes in the cgroup are throttled and put under a heavy reclaim pressure.
MemoryMax-
Absolute limit for the memory usage. You can use the kilo (K), mega (M), giga (G), tera (T) suffixes, for example
MemoryMax=1G. MemorySwapMax- Hard limit on the swap usage.
When you exhaust your memory limit, the Out-of-memory (OOM) killer will stop the running service. To prevent this, lower the OOMScoreAdjust= value to increase the memory tolerance.
Additional resources
26.7. Configuring I/O bandwidth by using systemd
To improve the performance of a specific service in RHEL 8, you can allocate I/O bandwidth resources to that service by using systemd.
To do so, you can use the following I/O configuration options:
- IOWeight
- IODeviceWeight
- IOReadBandwidthMax
- IOWriteBandwidthMax
- IOReadIOPSMax
- IOWriteIOPSMax
Procedure
To set a I/O bandwidth configuration option using systemd:
Check the assigned values of the I/O bandwidth configuration option in the service of your choice:
$ systemctl show --property <I/O bandwidth configuration option> <service name>Set the required value of the I/O bandwidth configuration option as a
root:# systemctl set-property <service name> <I/O bandwidth configuration option>=<value>
The cgroup properties are applied immediately after they are set. Therefore, the service does not need to be restarted.
Verification
To verify whether you successfully changed the required value of the I/O bandwidth configuration option for your service, enter:
$ systemctl show --property <I/O bandwidth configuration option> <service name>
26.8. I/O bandwidth configuration options for systemd
To manage the block layer I/O policies by using systemd, the following configuration options are available:
IOWeight- Sets the default I/O weight. The weight value is used as a basis for the calculation of how much of the real I/O bandwidth the service receives in relation to the other services.
IODeviceWeightSets the I/O weight for a specific block device.
For example,
IODeviceWeight=/dev/disk/by-id/dm-name-rhel-root 200.IOReadBandwidthMax,IOWriteBandwidthMaxSets the absolute bandwidth per device or a mount point.
For example,
IOWriteBandwith=/var/log 5M.Notesystemdhandles the file-system-to-device translation automatically.IOReadIOPSMax,IOWriteIOPSMax- Sets the absolute bandwidth in Input/Output Operations Per Second (IOPS).
Weight-based options are supported only if the block device is using the CFQ I/O scheduler. No option is supported if the device uses the Multi-Queue Block I/O queuing mechanism.
Additional resources
26.9. Configuring CPUSET controller by using systemd
With the systemd resource management API, you can configure limits on a set of CPUs and NUMA nodes that a service can use. This limit restricts access to system resources used by the processes. The requested configuration is written in the cpuset.cpus and cpuset.mems files.
However, the requested configuration may not be used, as the parent cgroup limits either cpus or mems. To access the current configuration, the cpuset.cpus.effective and cpuset.mems.effective files are exported to the users.
Procedure
To set
AllowedCPUs:# systemctl set-property <service name>.service AllowedCPUs=<value>For example:
# systemctl set-property <service name>.service AllowedCPUs=0-5To set
AllowedMemoryNodes:# systemctl set-property <service name>.service AllowedMemoryNodes=<value>For example:
# systemctl set-property <service name>.service AllowedMemoryNodes=0
