In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-15 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >
Share
Shulou(Shulou.com)06/03 Report--
1. Cgroup
(1) Docker controls the resource quota used by the container through Cgroup, including CPU, memory and disk, which basically covers the common resource quota and usage control.
(2) Cgroup is a mechanism provided by the Linux kernel to limit, record and isolate the physical resources used by the process group.
Cgroup subsystem:
1. Blkio: set the input and output control that limits each block device
2. Cpu: use the scheduler to provide cpu access to cgroup tasks
3. Cpuacct: report on cpu resources that generate cgroup tasks
4. Cpuset: if it is a multi-core cpu, this subsystem allocates separate cpu and memory to the cgroup task
5. Devices: allow or deny cgroup task access to the device
6. Freezer: suspend and resume cgroup tasks
7. Memory: set the memory limit for each cgroup and generate memory resource reports
8. Net_cls: Mark each network packet for cgroup convenience
9. Ns: namespace subsystem
10. Perf_event: increased monitoring and tracking capability for each cgroup, which can monitor all threads belonging to a particular cgroup and threads running on a particular CPU.
Use stress tools to test CPU and memory
First use Dockerfile to create a Centos-based stress tool image:
[root@localhost ~] # mkdir / opt/stress [root@localhost ~] # cd / opt/stress/ [root@localhost stress] # vim DockerfileFROM centos:7RUN yum install-y wgetRUN wget-O / etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repoRUN yum install-y stress [root@localhost stress] # docker build-t centos:stress. / / create an image
(1) use the following command to create a container. The-cpu-shares parameter value in the command does not guarantee that you can get 1 vcpu or how many GHz CPU resources, it is only an elastic weighting value.
[root@localhost stress] # docker run-itd-- cpu-shares 100 centos:stress08a203033c051098fd6294cd8ba4e2fa8baa18cefb793c6c4cd655c0f28cabc0
Note: by default, the share of CPU per Docker container is 1024, and the share of a single container is meaningless. The effect of container CPU weighting is only reflected when multiple containers are running at the same time.
For example, the CPU shares of two containers An and B are 1000 and 500, respectively. When CPU allocates time slices, container An is twice as likely to get CPU time slices as container B. However, the result of the allocation depends on the running status of the host and other containers at that time, and in fact, there is no guarantee that container A will get the CPU time slice. For example, if the process of container An is always idle, container B can get more CPU time slices than container A. In extreme cases, for example, there is only one container running on the host, and even if its CPU share is only 50%, it can monopolize the CPU resources of the entire host.
For example, Cgroup takes effect only when the resources allocated by the container are scarce, that is, when the resources used by the container need to be limited. Therefore, it is not possible to determine how much CPU resources are allocated to a container based solely on its CPU share, and the result of resource allocation depends on the CPU allocation of other containers running at the same time and the running of processes in the container. Through cpu share, you can set the priority for the container to use CPU.
For example, start two containers and run to see the percentage of CPU usage:
1 、
/ / the container generates 10 sub-function processes: [root@localhost stress] # docker run-itd-- name cpu512-- cpu-shares 512centos:stress stress-c 1099086cce962308fdb5417df189571e39f375ab2c067887cbac48e773225f25c7// enters the container and then uses the top command to check the cpu usage: [root@localhost stress] # docker exec-it 99086cce9623 bash [root@99086cce9623 /] # top.. .... .... .... .. Press Q to exit, and [root@99086cce9623 /] # exit / / exit the entire container
2. At this point, we can open another container for comparison:
[root@localhost stress] # docker run-itd-- name cpu1024-- cpu-shares 1024 centos:stress stress-c 1081e29988fce779c6b3e10fb8570ae2358db4090e1987202bb7919260287eca66 [root@localhost stress] # docker exec-it 81e29988fce7 bash [root@81e29988fce7 /] # top
By entering the container and observing the% CPU of the two containers, we can find that the ratio is 1:2
Third, CPU cycle restrictions:
Docker provides-- cpu-period,-cpu-quota two parameters to control the CPU clock cycle to which the container can be allocated.
-cpu-period: it is used to specify how often the container will reallocate the use of CPU.
-cpu-quota: is used to specify the maximum amount of time you can spend running this container during this cycle.
Unlike-- cpu-shares. This configuration specifies an absolute value, and the container's use of CPU resources will never exceed the configured value.
Note:
The units of cpu-period and cpu-quota are microseconds
The minimum value of cpu-period is 1000 microseconds, the maximum value is 1 second, and the default value is 0.1 seconds.
The default value of cpu-quota is-1, which means no control
The cpu-period and cpu-quota parameters are generally used in conjunction.
For example:
The container process needs to use a single CPU for 0.2s per second. You can set cpu-period to 1000000 (that is, 1 second) and cpu-quota to 200000 (0.2s). Of course, in multi-core cases, if the container process is allowed to occupy two CPU completely, you can set cpu-period to 100000 (that is, 0.1s) and cpu-quota to 200000 (0.2s).
[root@localhost stress] # docker run-itd-- cpu-period 100000-- cpu-quota 200000 centos:stress3f2a577cf6a281347338cbf9734440b3b8a29e771dc4890a9f243eb0773f6c09 [root@localhost stress] # docker exec-it 3f2a577cf6a2 bash [root@3f2a577cf6a2 /] # cat / sys/fs/cgroup/cpu/cpu.cfs_period_us 100000 [root@3f2a577cf6a2 /] # cat / sys/fs/cgroup/cpu/cpu.cfs_quota_us 200000
4. CPU Core control:
For multicore CPU servers, Docker can also control which CPU cores the container uses to run, that is, using the-- cpuset-cpus parameter. This is especially useful for servers with multiple CPU to optimize the performance of containers that require high-performance computing.
[root@localhost ~] # docker run-itd-- name cpu02-- cpuset-cpus=0-2 centos:stress76994f5d310de48ee635f69270f7c9b4cba1e65aad935ff1e0d6e098441104eb// executes this command (host is required to be quad-core), which means that the created container can only use 0, 1, 2 cores. [root@localhost ~] # docker exec-it 76994f5d310d bash / / enter the container [root@76994f5d310d /] # cat / sys/fs/cgroup/cpuset/cpuset.cpus0-2
You can see the binding relationship between the processes in the container and the CPU kernel through the following instructions to achieve the purpose of the CPU kernel:
[root@localhost ~] # docker exec 76994f5d310d taskset-c-p 1pid 1 runs current affinity list: 0-2 pid / the first process number inside the container is 1, which is bound to the specified CPU to run.
5. Mixed use of CPU quota control parameters:
Use the cpuset-cpus parameter to specify that container A uses CPU kernel 0 and container B only uses CPU kernel 1; only these two containers use the corresponding CPU kernel on the host, they each own all the kernel resources, and cpu-shares has no obvious effect. Cpuset-cpus and cpuset-mems parameters are only valid on servers on multi-core and multi-memory nodes, and must match the actual physical configuration, otherwise the purpose of resource control can not be achieved. When the system has multiple CPU cores, you need to set the container CPU kernel through the cpuset-cpus parameter in order to test conveniently.
[root@localhost ~] # docker run-itd-- name cpu3-- cpuset-cpus 1-- cpu-shares 512 centos:stress stress-c 1d6e122af832297a05b6993ea3146a2a62969557989933ac9f1bf59f2a1de5c50 [root@localhost ~] # docker exec-it d6e122af8322 bash [root@d6e122af8322 /] # top / / top, press 1 to see the occupancy of each core
Let's create another container:
[root@localhost] # docker run-itd-- name cpu4-- cpuset-cpus 3-- cpu-shares 1024 centos:stress stress-c 1d375a1ba761a711d55a01d95c7a5d494e62f86d447d36422be666cacf6483ca1 [root@localhost ~] # docker exec-it d375a1ba761a bash [root@d375a1ba761a /] # top
VI. Memory limit:
Similar to the operating system, the memory available to the container consists of two parts: physical memory and Swap
Docker controls container memory usage through the following two sets of parameters:
-m or-- memory: sets the usage limit of memory, such as 100m, 1024m
-memory-swap: sets the usage limit of memory + swap.
For example, execute the following command to allow the container to use up to 200m of memory and 300m of swap:
[root@localhost] # docker run-it-m 200m-- memory-swap=300M progrium/stress-- vm 1-- vm-bytes 280M//-- vm 1: start a memory worker thread;-- vm-bytes 280m: allocate 280m memory per thread If the worker thread allocates more than 300m memory, the allocated memory exceeds the limit, the stress thread reports an error, and the container exits: [root@localhost ~] # docker run-it-m 200m-memory-swap=300M progrium/stress-- vm 1-- vm-bytes 310m
Seven: restrictions on Block IO:
By default, all containers can read and write disks equally, and the priority of the container block IO can be changed by setting the-- blkio-weight parameter.
-blkio-weight is similar to-- cpu-shares, with a relative weight value set to 500 by default
In the following example, Container A reads and writes disks twice as wide as Container B.
[root@localhost] # docker run-it-- name container_A-- blkio-weight 600centos:stress [root@0f9b8d716206 /] # cat / sys/fs/cgroup/blkio/blkio.weight [root@localhost ~] # docker run-it-name container_B-- blkio-weight 300 centos:stress [root@55bdce1cab5d /] # cat / sys/fs/cgroup/blkio/blkio.weight
VIII. Restrictions on bps and iops:
(1) bps: byte per second, the amount of data read and written per second
(2) iops: is io per second, the number of IO per second
(3) bps and iops can be controlled by the following parameters:
-device-read-bps: restrict reading of the bps of a device
Device-write-bps: restrict writing to the bps of a device
Device-read-iops: restrict reading of a device's iops
Device-write-iops: restrict writing to the iops of a device.
For example:
Limit the rate at which the container writes / dev/sda disks to 5MB/s:
[root@localhost] # docker run-it-- device-write-bps / dev/sda:5MB centos:stress
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.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.