While running critical services on the server. We might want to restrict certain services or guarantee certain amount of resources to specific services. We want controlling resource limit on services using cgroup.
We can restrict / guarantee certain amount of resources like cpu, memory and block I/O to critical services using cgroups.
Control groups (cgroups) are a Linux kernel mechanism for fine-grained control of resources. With cgroups, resources are placed in controllers representing the type of resource; for example, cpu for CPU time, memory for memory usage, and blkio for disk I/O.
Controllers can be subdivided, as represented by a tree structure, with different weights or limits associated to branches and leaves, which are the cgroups. Each cgroup has zero or more processes associated with it. Resources are shared equally in a cgroup by default, but different limits and weights can be set on child cgroups as long as they do not exceed the parent cgroup limits. New cgroups inherit the limits set on its parent cgroup, unless explicitly overridden.
The hierarchy (control groups tree) is defined by providing structure to
cgroups virtual file system, mounted by default on the
/sys/fs/cgroup/ directory. It is done manually by creating and removing sub-directories in
/sys/fs/cgroup/. Alternatively, by using the
systemd system and service manager.
The resource controllers (a kernel component) then modify the behavior of processes in
cgroups by limiting, prioritizing or allocating system resources, (such as CPU time, memory, network bandwidth, or various combinations) of those processes.
The added value of
cgroups is process aggregation which enables division of hardware resources among applications and users. Thereby an increase in overall efficiency, stability and security of users’ environment can be achieved.
Controlling Resource Limit on Services using CGroup
Managing cgroups with systemd daemon is a simple way to handle complex resource configurations. By default, systemd subdivides the cpu, cpuacct, blkio, and memory cgroups into three equal slices: system for system services and daemons, machine for virtual machines and containers, and user for user sessions.
I don’t want to go into deep dive of cgroups in this post. I just want you to understand how to limit / guarantee resources to a important service using cgroups.
You can learn more on cgroups in this post on Red Hat Blog.
The easiest way is to to use or implement cgroups is by using “systemctl” command.
Using the systemctl set-property command sets the specified unit properties at runtime.
Changes are applied immediately and stored persistently.
In this example I am limiting sshd service to use only 500M of phyisical memory using cgroups and implemented using “systemctl set-property” command .
As expected sshd service is currently running and is not under any control. So the service can dominate a resource. We can verify it by using “systemctl status sshd” command.
Now lets use systemctl set-property command to configure cgroups limit on sshd service.
systemctl set-property sshd.service MemoryAccounting=yes
systemctl set-property sshd.service MemoryLimit=500M
I can slso add the –runtime option in the systemctl set-property command, which will applies the changes immediately, but the settings will not be retained after a service reload. So, I am not using it.
You might need to reload the systemctl daemon using “systemctl daemon-reload” command
Then you can use the “systemctl restart sshd” to reload the service itself.
systemctl restart sshd
Check the service status again and you will find the limit imposed on the service using cgroups. It will also automatically create a directory and the configurations are stored permanently in the file.
It will also automatically create a directory “sshd.service.d” under “/etc/systemd/system/” and the limits imposed using systemctl commands will be permanently stored there in .conf files.
So the changes are permanent and will be available across the reboot.
These controlling resource limits on services using cgroup will also be available and checked even after you restart sshd service.