1 00:00:00,000 --> 00:00:11,760 The main system to manage resource allocation is C-groups, currently integrated in system 2 00:00:11,760 --> 00:00:17,559 D. C-groups are used for resource allocation and because of C-groups, processes can be 3 00:00:17,559 --> 00:00:23,440 limited to the maximum amount of resources that they can use. Without C-groups, a memory 4 00:00:23,440 --> 00:00:28,799 leak may lead to a situation where an application is claiming all the available memory. With 5 00:00:28,799 --> 00:00:33,759 C-groups, you can just say to your application, hey, you can't have more than half a gigabyte 6 00:00:33,759 --> 00:00:40,320 of memory. And once it reaches this half a gig of memory, it will be over. C-groups on 7 00:00:40,320 --> 00:00:45,279 modern Linux are managed through system D. And in the C-group configuration, we have 8 00:00:45,279 --> 00:00:51,000 slices at the highest level in the organization. Slices are parts of the operating system which 9 00:00:51,000 --> 00:00:57,400 are used for resource allocation. There is a system slice, which is for privileged processes. 10 00:00:57,400 --> 00:01:02,840 The machine slice is for virtual machines and containers. And user slice is for non-privileged 11 00:01:02,840 --> 00:01:09,480 processes. And by default, all of these slices have a claim to an equal amount of system 12 00:01:09,480 --> 00:01:16,720 resources. Within a slice, resources are further divided. And within the slice, every single 13 00:01:16,720 --> 00:01:22,080 service is a pair to the other servers, and all services have a claim to an equal amount 14 00:01:22,080 --> 00:01:26,980 of system resources. Now, if you account for relative resource weight, that is something 15 00:01:26,980 --> 00:01:33,379 that happens within the slice. And I'm going to show you how that works for CPU weight. 16 00:01:33,379 --> 00:01:38,379 CPU weight is a parameter previously defined as CPU shares, which defines the relative 17 00:01:38,379 --> 00:01:44,620 weight of a process regarding CPU load as compared to other processes. By default, all 18 00:01:44,620 --> 00:01:49,300 processes have the same CPU weight. But guess what? You can change that. And that's what 19 00:01:49,300 --> 00:01:56,699 I want to show you. So if process 1 has a CPU weight of 1024, and process 2 has a CPU 20 00:01:56,699 --> 00:02:04,739 weight of 512, then process 1 gets twice the amount of CPU cycles. The CPU weight is 21 00:02:04,739 --> 00:02:12,020 determined between pair processes running in the same slice. So if you have a user space 22 00:02:12,020 --> 00:02:18,940 slice that has a CPU weight of 20,000, and in system space, you only have CPU weight 23 00:02:18,940 --> 00:02:25,419 of 1,000, it doesn't mean that user space process is getting 20 times the amount. No, 24 00:02:25,419 --> 00:02:30,139 that is something that is determined at the slice level. Another important parameter is 25 00:02:30,139 --> 00:02:35,259 memory min and memory max. This allows you to set limits to the amount of memory which 26 00:02:35,259 --> 00:02:41,339 is available for processes. And a process will get an out-of-memory, or ohm, error when 27 00:02:41,339 --> 00:02:46,979 trying to allocate more memory. Out-of-memory, well, pretty obvious to understand. That's 28 00:02:46,979 --> 00:02:53,380 a kernel just saying, hey, I don't have anything else. Let me demonstrate how to manage cgroups. 29 00:02:54,100 --> 00:03:00,339 First, I want to make this a one-CPU system. If we use LSCPU, need to pipe it through less 30 00:03:00,339 --> 00:03:04,899 because it's giving a lot of output, there you can see that I have a two-CPU system. 31 00:03:05,539 --> 00:03:09,619 And I want to disable one of them. And I can do that by writing a parameter to the 32 00:03:09,619 --> 00:03:19,539 sys pseudo file system. So I'm writing a zero to sys bus CPU devices CPU1 online. 33 00:03:20,100 --> 00:03:25,460 And then when I use LSCPU again, I can see that there is one CPU that is currently offline. 34 00:03:26,500 --> 00:03:33,059 Good. Next thing, we need access to the course git repository. So you may have to install the 35 00:03:33,059 --> 00:03:40,179 git client before you can. And once you have done it, you can use git clone https colon 36 00:03:41,139 --> 00:03:47,460 slash slash github.com slash Sander van Vugt slash Linux plus. 37 00:03:50,820 --> 00:03:56,979 Then within the Linux plus directory, you will find the stress one service and stress two service. 38 00:03:56,979 --> 00:04:04,419 I need to check this. Okay, so in the git repository, you will find two systemd unit files. 39 00:04:05,300 --> 00:04:12,820 And what it is about is this setting, CPU weight is 100. So the systemd unit is running DD. And 40 00:04:12,820 --> 00:04:19,619 DD is maxing out CPU cycles. So I'm doing that twice. One of them has a CPU weight of 100. And 41 00:04:19,619 --> 00:04:26,899 the other one has a CPU weight of 200. And we will see the difference. So to work with this, 42 00:04:26,899 --> 00:04:36,339 I need to copy stress to etc systemd system. And then systemctl daemon reload might be a good idea 43 00:04:36,339 --> 00:04:43,619 to make sure that systemd picks up the changes. And I'm going to use systemctl start stress one, 44 00:04:44,179 --> 00:04:48,899 as well as systemctl start stress two. And then we are going to observe in top. 45 00:04:49,859 --> 00:04:56,579 And what do we see in top? Well, pretty obvious. You can see one DD process is getting twice the 46 00:04:56,579 --> 00:05:02,579 amount as the other DD process. And that is because of the CPU weight that has been set. 47 00:05:03,459 --> 00:05:08,660 Now I'm going to open a small shell window. Let me do that on top of what we see right here. 48 00:05:11,459 --> 00:05:17,380 I want it to be small. And the thing about it is that this is a non-privileged user. 49 00:05:17,459 --> 00:05:21,700 And the non-privileged user is running while true, do, true, done. 50 00:05:24,579 --> 00:05:30,820 And what do we see? As you can see right here, a batch process is kicking in. 51 00:05:30,820 --> 00:05:37,380 And the batch process is hitting at almost 50%. Now why is that? That is because from a slice 52 00:05:37,380 --> 00:05:43,220 perspective, the user slice and the system slice are equal. And the user slice is the same 53 00:05:43,220 --> 00:05:49,779 entitlement as the system slice. The DD processes are within the system slice. So the fact that one 54 00:05:49,779 --> 00:05:55,220 of the DD processes has 200 doesn't matter at the user slice level. And that's why. 55 00:05:57,459 --> 00:06:04,980 Now there is something that you can do about it. And that is by changing the settings 56 00:06:04,980 --> 00:06:14,660 on the system slice. So let me use systemctl.setproperty. System.slice. 57 00:06:17,299 --> 00:06:21,140 CPU weight is 800. 58 00:06:23,779 --> 00:06:30,339 And then I'm doing my usual level while true, do, true, done again. And that's kicking in right now. 59 00:06:30,339 --> 00:06:36,579 And do you see what is happening? System slice is getting eight times as many CPU resources as 60 00:06:36,579 --> 00:06:43,220 the user slice. And that is what is really limiting the process in the user slice. At the same time, 61 00:06:43,220 --> 00:06:49,459 you may also have noticed that the system is becoming really slow. And that is because my 62 00:06:49,459 --> 00:06:55,059 Q command, which I'm using right here, it's happening within the user slice. It's becoming 63 00:06:55,059 --> 00:07:01,859 so slow that it is almost unacceptable. But that is what is going on. And that is why I'm going to 64 00:07:02,579 --> 00:07:10,019 change the setting back. And I'm making it 100 again. And let me kill all the DD processes 65 00:07:10,579 --> 00:07:12,500 because this is all for this demo.