2023年7月3日发(作者：)

Docker限制容器可⽤的CPU的⽅式默认情况下容器可以使⽤的主机 CPU 资源是不受限制的。和内存资源的使⽤⼀样，如果不对容器可以使⽤的 CPU 资源进⾏限制，⼀旦发⽣容器内程序异常使⽤ CPU 的情况，很可能把整个主机的 CPU 资源耗尽，从⽽导致更⼤的灾难。本⽂将介绍如何限制容器可以使⽤的 CPU 资源。本⽂的 demo 中会继续使⽤《》⼀⽂中创建的 docker 镜像 u-stress 进⾏压⼒测试，⽂中就不再过多的解释了。限制可⽤的 CPU 个数在 docker 1.13 及更⾼的版本上，能够很容易的限制容器可以使⽤的主机 CPU 个数。只需要通过 --cpus 选项指定容器可以使⽤的 CPU 个数就可以了，并且还可以指定如 1.5 之类的⼩数。接下来我们在⼀台有四个 CPU 且负载很低的主机上进⾏ demo演⽰：通过下⾯的命令创建容器，--cpus=2 表⽰容器最多可以使⽤主机上两个 CPU：$ docker run -it --rm --cpus=2 u-stress:latest /bin/bash然后由 stress 命令创建四个繁忙的进程消耗 CPU 资源：# stress -c 4我们先来看看 docker stats 命令的输出：容器 CPU 的负载为 200%，它的含义为单个 CPU 负载的两倍。我们也可以把它理解为有两颗 CPU 在 100% 的为它⼯作。再让我们通过 top 命令看看主机 CPU 的真实负载情况：哈哈，有点⼤跌眼镜！实际的情况并不是两个 CPU 负载 100%，⽽另外两个负载 0%。四个 CPU 的负载都是 50%，加起来容器消耗的 CPU 总量就是两个 CPU 100% 的负载。看来对于进程来说是没有 CPU 个数这⼀概念的，内核只能通过进程消耗的 CPU 时间⽚来统计出进程占⽤ CPU 的百分⽐。这也是我们看到的各种⼯具中都使⽤百分⽐来说明 CPU 使⽤率的原因。严谨起见，我们看看 docker 的官⽅⽂档中是如何解释 --cpus 选项的：果然，⼈家⽤的是 "how much"，不可数的！并且 --cpus 选项⽀持设为⼩数也从侧⾯说明了对 CPU 的计量只能是百分⽐。看来笔者在本⽂中写的 "CPU 个数" 都是不准确的。既然不准确，为什么还要⽤？当然是为了容易理解。况且笔者认为在 --cpus 选项的上下⽂中理解为 "CPU 个数" 并没有问题(有兴趣的同学可以读读 ，⼈家的初衷也是要表⽰ CPU 个数的)。虽然 --cpus 选项⽤起来很爽，但它毕竟是 1.13 才开始⽀持的。对于更早的版本完成同样的功能我们需要配合使⽤两个选项：--cpu-period 和 --cpu-quota(1.13 及之后的版本仍然⽀持这两个选项)。下⾯的命令实现相同的结果：复制代码 代码如下:$ docker run -it --rm --cpu-period=100000 --cpu-quota=200000 u-stress:latest /bin/bash这样的配置选项是不是让⼈很傻眼呀！100000 是什么？200000 ⼜是什么？ 它们的单位是微秒，100000 表⽰ 100 毫秒，200000 表⽰ 200 毫秒。它们在这⾥的含义是：在每 100 毫秒的时间⾥，运⾏进程使⽤的 CPU 时间最多为 200 毫秒(需要两个 CPU 各执⾏ 100 毫秒)。要想彻底搞明⽩这两个选项的同学可以参考：。我们要知道这两个选项才是事实的真相，但是真相往往很残忍！还好 --cpus 选项成功的解救了我们，其实它就是包装了 --cpu-period 和 --cpu-quota。指定固定的 CPU通过 --cpus 选项我们⽆法让容器始终在⼀个或某⼏个 CPU 上运⾏，但是通过 --cpuset-cpus 选项却可以做到！这是⾮常有意义的，因为现在的多核系统中每个核⼼都有⾃⼰的缓存，如果频繁的调度进程在不同的核⼼上执⾏势必会带来缓存失效等开销。下⾯我们就演⽰如何设置容器使⽤固定的 CPU，下⾯的命令为容器设置了 --cpuset-cpus 选项，指定运⾏容器的 CPU 编号为 1：$ docker run -it --rm --cpuset-cpus="1" u-stress:latest /bin/bash再启动压⼒测试命令：# stress -c 4然后查看主机 CPU 的负载情况：这次只有 Cpu1 达到了 100%，其它的 CPU 并未被容器使⽤。我们还可以反复的执⾏ stress -c 4 命令，但是始终都是 Cpu1在⼲活。再看看容器的 CPU 负载，也是只有 100%：--cpuset-cpus 选项还可以⼀次指定多个 CPU：$ docker run -it --rm --cpuset-cpus="1,3" u-stress:latest /bin/bash这次我们指定了 1，3 两个 CPU，运⾏ stress -c 4 命令，然后检查主机的 CPU 负载：Cpu1 和 Cpu3 的负载都达到了 100%。容器的 CPU 负载也达到了 200%：--cpuset-cpus 选项的⼀个缺点是必须指定 CPU 在操作系统中的编号，这对于动态调度的环境(⽆法预测容器会在哪些主机上运⾏，只能通过程序动态的检测系统中的 CPU 编号，并⽣成 docker run 命令)会带来⼀些不便。设置使⽤ CPU 的权重当 CPU 资源充⾜时，设置 CPU 的权重是没有意义的。只有在容器争⽤ CPU 资源的情况下， CPU 的权重才能让不同的容器分到不同的 CPU ⽤量。--cpu-shares 选项⽤来设置 CPU 权重，它的默认值为 1024。我们可以把它设置为 2 表⽰很低的权重，但是设置为 0 表⽰使⽤默认值 1024。下⾯我们分别运⾏两个容器，指定它们都使⽤ Cpu0，并分别设置 --cpu-shares 为 512 和 1024：$ 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在两个容器中都运⾏ stress -c 4 命令。此时主机 Cpu0 的负载为 100%：容器中 CPU 的负载为：两个容器分享⼀个 CPU，所以总量应该是 100%。具体每个容器分得的负载则取决于 --cpu-shares 选项的设置！我们的设置分别是 512 和 1024，则它们分得的⽐例为 1:2。在本例中如果想让两个容器各占 50%，只要把 --cpu-shares 选项设为相同的值就可以了。总结相⽐限制容器⽤的内存，限制 CPU 的选项要简洁很多。但是简洁绝对不是简单，⼤多数把复杂东西整简单的过程都会丢失细节或是模糊⼀些概念，⽐如从 --cpu-period 和 --cpu-quota 选项到 --cpus 选项的进化。对于使⽤者来说这当然是好事，可以减缓我们的学习曲线，快速⼊⼿。以上就是本⽂的全部内容，希望对⼤家的学习有所帮助，也希望⼤家多多⽀持。