The main system to manage resource allocation is C-groups, currently integrated in system
D. C-groups are used for resource allocation and because of C-groups, processes can be
limited to the maximum amount of resources that they can use. Without C-groups, a memory
leak may lead to a situation where an application is claiming all the available memory. With
C-groups, you can just say to your application, hey, you can't have more than half a gigabyte
of memory. And once it reaches this half a gig of memory, it will be over. C-groups on
modern Linux are managed through system D. And in the C-group configuration, we have
slices at the highest level in the organization. Slices are parts of the operating system which
are used for resource allocation. There is a system slice, which is for privileged processes.
The machine slice is for virtual machines and containers. And user slice is for non-privileged
processes. And by default, all of these slices have a claim to an equal amount of system
resources. Within a slice, resources are further divided. And within the slice, every single
service is a pair to the other servers, and all services have a claim to an equal amount
of system resources. Now, if you account for relative resource weight, that is something
that happens within the slice. And I'm going to show you how that works for CPU weight.
CPU weight is a parameter previously defined as CPU shares, which defines the relative
weight of a process regarding CPU load as compared to other processes. By default, all
processes have the same CPU weight. But guess what? You can change that. And that's what
I want to show you. So if process 1 has a CPU weight of 1024, and process 2 has a CPU
weight of 512, then process 1 gets twice the amount of CPU cycles. The CPU weight is
determined between pair processes running in the same slice. So if you have a user space
slice that has a CPU weight of 20,000, and in system space, you only have CPU weight
of 1,000, it doesn't mean that user space process is getting 20 times the amount. No,
that is something that is determined at the slice level. Another important parameter is
memory min and memory max. This allows you to set limits to the amount of memory which
is available for processes. And a process will get an out-of-memory, or ohm, error when
trying to allocate more memory. Out-of-memory, well, pretty obvious to understand. That's
a kernel just saying, hey, I don't have anything else. Let me demonstrate how to manage cgroups.
First, I want to make this a one-CPU system. If we use LSCPU, need to pipe it through less
because it's giving a lot of output, there you can see that I have a two-CPU system.
And I want to disable one of them. And I can do that by writing a parameter to the
sys pseudo file system. So I'm writing a zero to sys bus CPU devices CPU1 online.
And then when I use LSCPU again, I can see that there is one CPU that is currently offline.
Good. Next thing, we need access to the course git repository. So you may have to install the
git client before you can. And once you have done it, you can use git clone https colon
slash slash github.com slash Sander van Vugt slash Linux plus.
Then within the Linux plus directory, you will find the stress one service and stress two service.
I need to check this. Okay, so in the git repository, you will find two systemd unit files.
And what it is about is this setting, CPU weight is 100. So the systemd unit is running DD. And
DD is maxing out CPU cycles. So I'm doing that twice. One of them has a CPU weight of 100. And
the other one has a CPU weight of 200. And we will see the difference. So to work with this,
I need to copy stress to etc systemd system. And then systemctl daemon reload might be a good idea
to make sure that systemd picks up the changes. And I'm going to use systemctl start stress one,
as well as systemctl start stress two. And then we are going to observe in top.
And what do we see in top? Well, pretty obvious. You can see one DD process is getting twice the
amount as the other DD process. And that is because of the CPU weight that has been set.
Now I'm going to open a small shell window. Let me do that on top of what we see right here.
I want it to be small. And the thing about it is that this is a non-privileged user.
And the non-privileged user is running while true, do, true, done.
And what do we see? As you can see right here, a batch process is kicking in.
And the batch process is hitting at almost 50%. Now why is that? That is because from a slice
perspective, the user slice and the system slice are equal. And the user slice is the same
entitlement as the system slice. The DD processes are within the system slice. So the fact that one
of the DD processes has 200 doesn't matter at the user slice level. And that's why.
Now there is something that you can do about it. And that is by changing the settings
on the system slice. So let me use systemctl.setproperty. System.slice.
CPU weight is 800.
And then I'm doing my usual level while true, do, true, done again. And that's kicking in right now.
And do you see what is happening? System slice is getting eight times as many CPU resources as
the user slice. And that is what is really limiting the process in the user slice. At the same time,
you may also have noticed that the system is becoming really slow. And that is because my
Q command, which I'm using right here, it's happening within the user slice. It's becoming
so slow that it is almost unacceptable. But that is what is going on. And that is why I'm going to
change the setting back. And I'm making it 100 again. And let me kill all the DD processes
because this is all for this demo.