docker资源限制

在传统虚拟化中, 如在VMware中, 有对CPU核心数, 内存,硬盘空间等限制

container 在run起来的时候, 并没有做资源限制, 但是默认container 会使用最大资源

# 查看容器的资源使用状态
docker stats
#一台物理机启动一个容器会使用最大资源, 两台,三台...都会使用到最大资源, 那么对容器的稳定性,造成一些大的伤害
#所以需要对容器做资源限制

cgroup

cgroup(Linux Control Group)是Linux内核对资源限制做的支持, 用来控制, 支持, 与分离一个进程组群的资源(如CPU, 内存,磁盘IO等), 其实就是在2006年, 谷歌工程师发起的进程容器的项目

cgroup限制CPU使用量案例

// vim main.c
#include<stdio.h>
int main(void)
{ 
	int i = 0;
	for(;;) i++;
	return 0;
}

yum -y install gcc gcc-c++
gcc main.c
./a.out
# 接下来对资源进行限制

mount -t cgroup
cd /sys/fs/cgroup/ && cd cpu
#tasks目录下都是当前系统下的进程ID
cat tasks 
# 创建一个CPU子系统  (在cpu目录下)
mkdir Newtasks
cd NewTask && ls #此时已经将所有的父级控制文件, 复制到子系统下
cat tasks #但是tasks 中还没有添加任务
top #查看PID
echo "49385" > tasks 
cat tasks 

#调度周期与配额
#周期 10min, bob 进行资源CPU调用, 时间为2 min, 则资源占用为20%
#在linux操作系统中, CPU调度周期的最大值为100000
echo "30000" > cpu.cfs_quota_us
# 再次top查看资源占用情况只能达到30%

内存的资源限制

在默认情况下, 如果不对容器做任何限制, 容器能够占用当前系统所能够给容器提供的所有资源

docker 限制可以从Memory ,CPU, Block I/O 三个方面

OOME (Out Of Memory Exception )内存退出异常

我们把资源做如下分类

资源的分类

可压缩性资源

CPU

网络I/O

磁盘I/O

不可压缩性资源

内存

内存是不可压缩的, 一旦小于所需内存, 进程就无法正常工作, 如果进程所需资源越来越大, 当快要抢占完kernel 的资源时, 内核就会将其kill 掉, 抛出OOME异常

一旦发生OOME, 任何进程都有可能被杀死, 包括docker daemon, 所以需要调整docker daemon的优先级, 防止被内核关闭

docker 内存限制的选项

--memory-swap 和--memory 选项结合

内存的软限制, 首先使用到软限制, 如果还有一些必要需求, 则允许使用到硬限制, 必要的需求用完之后, 还需要释放至软限制.

--memory-swappiness 80 表示使用80% 的物理内存, 配合使用20%的虚拟内存

CPU的资源限制

默认情况下，如果不对容器做任何限制，容器能够占用当前系统中的所有 CPU 资源

大多数进程是采用CFS 调度算法(公平调用算法)
1.13 Docker 版本后支持实时调度算法(可以动态改变)

4核心CPU CPU序列为0 1 2 3

一个进程调用CPU时, CPU需要进行场景重建(加载库函数等), 所以进程的启动就需要等待CPU重建完成

-c 默认值为2048

cpu-period=0
--cpu-quota=0  # 周期和配额一起使用

NUMA 对称多处理器结构

当不开启NUMA时, 两个CPU 可以互相公用内存, 距离远的也能用, 但是传输效率相对较低

如果开启NUMA,则两个CPU的内存, 不能共享给另一个CPU, 提高了传输效率, 但是可能会部分内存浪费, 目前主流操作系统都默认打开NUMA.

docker run --name stress -it --rm -m 256m lorel/docker-stress-ng:latest stress -vm 2 

docker run --name stress -it --rm --cpus 2 lorel/docker-stress-ng:latest stress --cpu 8  

docker run --name stress -it --rm --cpuset-cpus 0 lorel/docker-stress-ng:latest stress --cpu 8