1 00:00:00,000 --> 00:00:11,880 The main system to manage resource allocation is C-groups, currently integrated in system 2 00:00:11,880 --> 00:00:17,520 D. C-groups are used for resource allocation, and because of C-groups, processes can be 3 00:00:17,520 --> 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,299 of memory, and once it reaches this half a gig of memory, it will be over. C-groups on 7 00:00:40,299 --> 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:27,000 of system resources. Now, if you account for relative resource weight, that is something 15 00:01:27,000 --> 00:01:33,400 that happens within the slice. And I'm going to show you how that works for CPU weight. 16 00:01:33,400 --> 00:01:38,400 CPU weight is a parameter previously defined as CPU shares, which defines the relative 17 00:01:38,400 --> 00:01:44,639 weight of a process regarding CPU load as compared to other processes. By default, all 18 00:01:44,639 --> 00:01:49,320 processes have the same CPU weight, but guess what? You can change that, and that's what 19 00:01:49,320 --> 00:01:56,720 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,720 --> 00:02:04,760 weight of 512, then process 1 gets twice the amount of CPU cycles. The CPU weight is 21 00:02:04,760 --> 00:02:12,039 determined between pair processes running in the same slice. So if you have a user space 22 00:02:12,039 --> 00:02:18,960 slice that has a CPU weight of 20,000, and in system space, you only have CPU weight 23 00:02:18,960 --> 00:02:25,520 of 1,000, doesn't mean that user space process is getting 20 times the amount. No, that is 24 00:02:25,520 --> 00:02:30,520 something that is determined at the slice level. Another important parameter is memory 25 00:02:30,520 --> 00:02:35,880 min and memory max. This allows you to set limits to the amount of memory which is available 26 00:02:35,880 --> 00:02:41,800 for processes. In a process, you'll get an out-of-memory, or ohm, error when trying to 27 00:02:41,800 --> 00:02:47,360 allocate more memory. Out-of-memory, well, pretty obvious to understand. That's a kernel 28 00:02:47,360 --> 00:02:53,399 just saying, hey, I don't have anything else. Let me demonstrate how to manage cgroups. 29 00:02:54,080 --> 00:03:00,360 First, I want to make this a one-CPU system. If we use LSCPU, need to pipe it through less 30 00:03:00,360 --> 00:03:05,800 because it's giving a lot of output, there you can see that I have a two-CPU system. 31 00:03:05,800 --> 00:03:10,160 And I want to disable one of them. And I can do that by writing a parameter to the sys 32 00:03:10,160 --> 00:03:20,600 pseudo file system. So I'm writing a zero to sys bus CPU devices CPU1 online. And then 33 00:03:20,720 --> 00:03:27,720 when I use LSCPU again, I can see that there is one CPU that is currently offline. Good. 34 00:03:27,720 --> 00:03:33,160 Next thing, we need access to the course git repository. So you may have to install the 35 00:03:33,160 --> 00:03:44,160 git client before you can. And once you have done that, you can use git clone https://github.com 36 00:03:44,160 --> 00:03:53,960 slash Sander van Vugt slash Linux plus. Then within the Linux plus directory, you will 37 00:03:53,960 --> 00:04:01,360 find the stress one service and stress two service. I need to check this. Okay, so in 38 00:04:01,360 --> 00:04:07,520 the git repository, you will find two systemd unit files. And what it is about is this setting 39 00:04:07,600 --> 00:04:14,960 CPU weight is 100. So the systemd unit is running DD. And DD is maxing out CPU cycles. 40 00:04:15,600 --> 00:04:21,040 So I'm doing that twice. One of them has a CPU weight of 100 and the other one has a CPU weight 41 00:04:21,040 --> 00:04:29,040 of 200. And we will see the difference. So to work with this, I need to copy stress to etc 42 00:04:29,600 --> 00:04:37,119 systemd system. And then systemctl daemon reload might be a good idea to make sure that 43 00:04:37,119 --> 00:04:45,679 systemd picks up the changes. And I'm going to use systemctl start stress one, as well as systemctl 44 00:04:45,679 --> 00:04:51,200 start stress two. And then we are going to observe in top. And what do we see in top? 45 00:04:52,480 --> 00:04:58,640 Well, pretty obvious. You can see one DD process is getting twice the amount as the other DD 46 00:04:58,640 --> 00:05:05,519 process. And that is because of the CPU weight that has been set. Now I'm going to open a small 47 00:05:05,519 --> 00:05:08,640 shell window. Let me do that on top of what we see right here. 48 00:05:11,440 --> 00:05:17,440 I want it to be small. And the thing about it is that this is a non-privileged user. 49 00:05:17,440 --> 00:05:21,679 And the non-privileged user is running well through do true done. 50 00:05:24,559 --> 00:05:30,799 And what do we see? As you can see right here, a batch process is kicking in. 51 00:05:30,799 --> 00:05:37,359 And the batch process is hitting at almost 50%. Now why is that? That is because from a slice 52 00:05:37,359 --> 00:05:43,200 perspective, the user slice and the system slice are equal. And the user slice has the same 53 00:05:43,200 --> 00:05:49,760 entitlement as the system slice. The DD processes are within the system slice. So the fact that one 54 00:05:49,760 --> 00:05:55,200 of the DD processes has 200 doesn't matter at the user slice level. And that's why. 55 00:05:55,440 --> 00:06:03,679 Now there is something that you can do about it. And that is by changing the settings on 56 00:06:03,679 --> 00:06:13,519 the system slice. So let me use systemctl.setproperty. System.slice. 57 00:06:13,519 --> 00:06:21,119 CPU weight is 800. 58 00:06:23,760 --> 00:06:30,079 And then I'm doing my usual level well through do true done again. And that's kicking in right 59 00:06:30,079 --> 00:06:36,160 now. And do you see what is happening? System slice is getting eight times as many CPU resources 60 00:06:36,160 --> 00:06:42,720 as the user slice. And that is what is really limiting the process in the user slice. At the 61 00:06:42,720 --> 00:06:48,239 same time, you may also have noticed that the system is becoming really slow. And that is 62 00:06:48,239 --> 00:06:54,559 because my Q command, which I'm using right here, it's happening within the user slice. It's 63 00:06:54,559 --> 00:07:01,200 becoming so slow that it is almost unacceptable. But that is what is going on. And that is why I'm 64 00:07:01,200 --> 00:07:10,000 going to change the setting back. And I'm making it 100 again. And let me kill all the DD processes 65 00:07:10,000 --> 00:07:12,559 because this is all for this demo.