docker容器的CPU配置

docker容器的CPU配置

Docker用Cgroup的方式限制硬件资源分配：

配置文件在/sys/fs/cgroup/下
原文地址:https://www.cnblogs.com/xiaouisme/p/6686532.html

（1）CPU份额控制

docker提供了–cpu-shares参数，在创建容器时指定容器所使用的CPU份额值。使用示例：
使用命令docker run -tid –cpu-shares 1024 ubuntu:stress，创建容器，则最终生成的cgroup的cpu份额配置可以下面的文件中找到：
root@ubuntu:~# cat /sys/fs/cgroup/cpu/docker/<容器的完整长ID>/cpu.shares
cpu-shares的值不能保证可以获得1个vcpu或者多少GHz的CPU资源，仅仅只是一个弹性的加权值。
默认情况下，每个docker容器的cpu份额都是1024。单独一个容器的份额是没有意义的，只有在同时运行多个容器时，容器的cpu加权的效果才能体现出来。例如，两个容器A、B的cpu份额分别为1000和500，在cpu进行时间片分配的时候，容器A比容器B多一倍的机会获得CPU的时间片，但分配的结果取决于当时主机和其他容器的运行状态，实际上也无法保证容器A一定能获得CPU时间片。比如容器A的进程一直是空闲的，那么容器B是可以获取比容器A更多的CPU时间片的。极端情况下，比如说主机上只运行了一个容器，即使它的cpu份额只有50，它也可以独占整个主机的cpu资源。
cgroups只在容器分配的资源紧缺时，也就是说在需要对容器使用的资源进行限制时，才会生效。因此，无法单纯根据某个容器的cpu份额来确定有多少cpu资源分配给它，资源分配结果取决于同时运行的其他容器的cpu分配和容器中进程运行情况。

（2）CPU周期控制

docker提供了–cpu-period、–cpu-quota两个参数控制容器可以分配到的CPU时钟周期。–cpu-period是用来指定容器对CPU的使用要在多长时间内做一次重新分配，而–cpu-quota是用来指定在这个周期内，最多可以有多少时间用来跑这个容器。跟–cpu-shares不同的是这种配置是指定一个绝对值，而且没有弹性在里面，容器对CPU资源的使用绝对不会超过配置的值。
cpu-period和cpu-quota的单位为微秒（μs）。cpu-period的最小值为1000微秒，最大值为1秒（10^6 μs），默认值为0.1秒（100000 μs）。cpu-quota的值默认为-1，表示不做控制。
举个例子，如果容器进程需要每1秒使用单个CPU的0.2秒时间，可以将cpu-period设置为1000000（即1秒），cpu-quota设置为200000（0.2秒）。当然，在多核情况下，如果允许容器进程需要完全占用两个CPU，则可以将cpu-period设置为100000（即0.1秒），cpu-quota设置为200000（0.2秒）。
使用示例：
使用命令docker run -tid –cpu-period 100000 –cpu-quota 200000 ubuntu，创建容器，则最终生成的cgroup的cpu周期配置可以下面的文件中找到：
root@ubuntu:~# cat /sys/fs/cgroup/cpu/docker/<容器的完整长ID>/cpu.cfs_period_us
100000
root@ubuntu:~# cat /sys/fs/cgroup/cpu/docker/<容器的完整长ID>/cpu.cfs_quota_us
200000

（3）CPU内核控制

对多核CPU的服务器，docker还可以控制容器运行限定使用哪些cpu内核和内存节点，即使用–cpuset-cpus和–cpuset-mems参数。对具有NUMA拓扑（具有多CPU、多内存节点）的服务器尤其有用，可以对需要高性能计算的容器进行性能最优的配置。如果服务器只有一个内存节点，则–cpuset-mems的配置基本上不会有明显效果。
使用示例：
命令docker run -tid –name cpu1 –cpuset-cpus 0-2 ubuntu，表示创建的容器只能用0、1、2这三个内核。最终生成的cgroup的cpu内核配置如下：
root@ubuntu:~# cat /sys/fs/cgroup/cpuset/docker/<容器的完整长ID>/cpuset.cpus 0-2
通过docker exec <容器ID> taskset -c -p 1(容器内部第一个进程编号一般为1)，可以看到容器中进程与CPU内核的绑定关系，可以认为达到了绑定CPU内核的目的。

Docker容器对CPU资源隔离的几种方式

http://www.dockone.io/article/1102