Shulou(Shulou.com)06/01 Report--

This article focuses on "how to create a docker image u-stress for stress testing", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to create a docker image u-stress for stress testing.

Limit the number of CPU available

On docker 1.13 and later, it is easy to limit the number of host CPU that a container can use. You only need to specify the number of CPU that the container can use with the-- cpus option, and you can also specify decimals such as 1.5. Next, let's do a demo demonstration on a host with four CPU and a low load:

Create the container with the following command,-- cpus=2 indicates that the container can use up to two CPU on the host:

$docker run-it-rm-cpus=2 u-stress:latest / bin/bash

The stress command then creates four busy processes that consume CPU resources:

# stress-c 4

Let's first look at the output of the docker stats command:

Haha, a little surprised! The actual situation is not that two CPU loads are 100%, while the other two loads are 0%. The load of all four CPU is 50%, so the total amount of CPU consumed by the container is 100% of the load of two CPU.

It seems that there is no concept of the number of CPU for a process, and the kernel can only count the percentage of CPU consumed by the process through the CPU time slice consumed by the process. This is why percentages are used to describe CPU usage in the various tools we see.

For rigor's sake, let's take a look at how the cpus option is explained in docker's official documentation:

Specify how much of the available CPU resources a container can use.

Sure enough, people use "how much", which is innumerable! And the-- cpus option support is set to decimal, which also indicates that CPU can only be measured as a percentage.

It seems that the number of CPU written by the author in this article >

Although the-- cpus option is nice to use, it wasn't supported until 1. 13. For earlier versions to do the same thing, we need to use two options together:-- cpu-period and-- cpu-quota (both options are still supported in versions 1.13 and later). The following command achieves the same result:

$docker run-it-rm-cpu-period=100000-cpu-quota=200000 u-stress:latest / bin/bash

This configuration option is not very silly ah! What is 100000? What is 200000? They are measured in microseconds, with 100000 for 100ms and 200000 for 200ms. What they mean here is that every 100ms of time, the CPU time used to run the process is up to 200ms (it takes 100ms for each CPU to execute). Students who want to thoroughly understand these two options can refer to: CFS BandWith Control. We need to know that these two options are the truth, but the truth is often cruel! Fortunately-the cpus option successfully saved us, but it is actually packaged-- cpu-period and-- cpu-quota.

Specify a fixed CPU

We can't make the container run on one or more CPU all the time with the-- cpus option, but we can do it with the-- cpuset-cpus option! This is very meaningful, because each core in today's multi-core system has its own cache, and if frequent scheduling processes are executed on different cores, it will inevitably lead to overhead such as cache invalidation. Let's demonstrate how to set the container to use a fixed CPU. The following command sets the-- cpuset-cpus option for the container and specifies that the CPU number of the running container is 1:

$docker run-it-rm-cpuset-cpus= "1" u-stress:latest / bin/bash

Start the stress test command again:

# stress-c 4

Then check the load of the host CPU:

Only Cpu1 has reached 100% this time, and other CPU has not been used by the container. We can also execute the stress-c 4 command over and over again, but Cpu1 is always working.

If you look at the CPU load of the container, it is only 100%:

Both Cpu1 and Cpu3 are loaded at 100%.

The CPU load of the container has also reached 200%:

One disadvantage of the cpuset-cpus option is that the number of CPU in the operating system must be specified, which is inconvenient for dynamically scheduled environments (it is impossible to predict which hosts the container will run on, but only through the program to dynamically detect the CPU number in the system and generate the docker run command).

Set the weight of using CPU

When CPU resources are sufficient, it is meaningless to set the weight of CPU. Only when containers compete for CPU resources can the weight of CPU allocate different CPU usage to different containers. The-- cpu-shares option is used to set the CPU weight, and its default value is 1024. We can set it to 2 to indicate a very low weight, but 0 means to use the default value of 1024.

Let's run two containers respectively, specify that they both use Cpu0, and set-- cpu-shares to 512 and 1024, respectively:

Docker run-it-- rm-- cpuset-cpus= "0"-- cpu-shares=512 u-stress:latest / bin/bash$ docker run-it-- rm-- cpuset-cpus= "0"-- cpu-shares=1024 u-stress:latest / bin/bash

Run the stress-c 4 command in both containers.

At this point, the load of the host Cpu0 is 100%:

The load of CPU in the container is:

The two containers share one CPU, so the total should be 100%. The specific load for each container depends on the setting of the-- cpu-shares option! If our settings are 512 and 1024 respectively, their share is 1:2. In this example, if you want each of the two containers to account for 50%, just set the-- cpu-shares option to the same value.

At this point, I believe you have a deeper understanding of "how to create a docker image u-stress for stress testing". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.