Docker与Cgroup资源限制结合内幕深入剖析-Docker商业环境实战
2010 年 8 月 26 日
专注于大数据及容器云核心技术解密，可提供全栈的大数据+云原生平台咨询方案，请持续关注本套博客。如有任何学术交流，可随时联系。更多内容请关注《数据云技术社区》公众号。
1 Linux Cgroup(新瓶装旧酒)
- Linux Cgroup最主要的作用是为一个进程组设置资源使用的上限，这些资源包括CPU、内存、磁盘、网络等。在linux中，Cgroup给用户提供的操作接口是文件系统，其以文件和目录的方式组织在/sys/fs/cgroup路径下。
- Cgroup的资源限制是通过目录进行控制的，比如：在/sys/fs/cgroup/cpu目录下面创建hello文件夹，将会自动生成一堆默认cpu限制文件。
2 Docker容器与Cgroup结合
- 初始化场景下：Docker容器没有启动。
- 因为Docker容器没有运行，/sys/fs/cgroup/cpu/docker目录下面没有对应资源限制，如下所示：
- 因为Docker容器没有运行，/sys/fs/cgroup/memory/docker目录下面没有对应资源限制，如下所示：
- 启动运行时容器时，在/sys/fs/cgroup/cpu/docker目录下面创建d65aa14f8c929631f83c267b5575b07771b148e2f200ba1756236104169ce917目录
docker run -itd --rm --cpu-shares 512 progrium/stress --cpu 1 --timeout 1000s 复制代码
- 如下就是启动运行时容器时对应的场景
3 Docker容器基于Cgroup进行压测
3.1 CPU份额测试
- 运行3个容器，指定容器的–cpu-share的值分别为512、512、1024，这3个容器使用CPU的时间比例为1:1:2，使用ctop或者top查看CPU利用率，理想的情况下，CPU占用接近25%、25%、50%
docker run -itd --rm --cpu-shares 512 progrium/stress --cpu 1 --timeout 1000s docker run -itd --rm --cpu-shares 512 progrium/stress --cpu 1 --timeout 100s docker run -itd --rm --cpu-shares 1024 progrium/stress --cpu 1 --timeout 100s 复制代码
- 启动三个Docker容器进程
- 查看CPU占比为1:1:2
- 查看/sys/fs/cgroup/cpu/docker目录下对应三个目录，分别是：4ba04effda39be626d3bd1945b90a43e4ff99471a3296e05616c58a1c11ba873,d65aa14f8c929631f83c267b5575b07771b148e2f200ba1756236104169ce917,fe2f33bad9d15e42b7b2941528394e256ea7e119f3f5a563029c032a30519e5e
- 查看cpu.shares限制文件对应的值512:512:1024
3.1 Memory份额测试
- 运行2个stress容器，测试内存的占用，每个容器产生4个线程，第一个容器每个线程消耗128MB内存，第二个容器的4个线程每个消耗256MB内存：
docker stop $(docker ps -q) & docker rm $(docker ps -aq) docker run --rm -it progrium/stress --cpu 2 --io 1 --vm 2 --vm-bytes 128M --timeout 60s docker run -itd --rm progrium/stress --vm 4 --vm-bytes 128M --timeout 100s docker run -itd --rm progrium/stress --vm 4 --vm-bytes 256M --timeout 100s [root@worker3 local]# docker run -itd --rm progrium/stress --vm 4 --vm-bytes 128M --timeout 100s 888b0a8b4afdd92e241d0446c63d940cb486559f86263a070577a3860e0f5356 [root@worker3 local]# docker run -itd --rm progrium/stress --vm 4 --vm-bytes 256M --timeout 100s 25cc7585895d2e5f9fee4a1723d5cc09464c426c9213854ce56e1d6bb3c1256d top - 23:31:52 up 2:23, 3 users, load average: 5.95, 3.93, 2.45 Tasks: 113 total, 9 running, 104 sleeping, 0 stopped, 0 zombie %Cpu(s): 10.7 us, 89.3 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 1872956 total, 853736 free, 821600 used, 197620 buff/cache KiB Swap: 0 total, 0 free, 0 used. 848116 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 30972 root 20 0 138380 75868 256 R 12.3 4.1 0:01.57 stress 30975 root 20 0 138380 21092 256 R 12.3 1.1 0:01.57 stress 31022 root 20 0 269452 158148 256 R 12.3 8.4 0:01.54 stress 31023 root 20 0 269452 133648 256 R 12.3 7.1 0:01.54 stress 31025 root 20 0 269452 135696 256 R 12.3 7.2 0:01.54 stress 30973 root 20 0 138380 71772 256 R 12.0 3.8 0:01.57 stress 30974 root 20 0 138380 28556 256 R 12.0 1.5 0:01.57 stress 31024 root 20 0 269452 31076 256 R 12.0 1.7 0:01.54 stress [root@worker3 docker]# ls 16a19075bbc6f7525bbcef670fcf920223d6a54396bad4393110fdf9c6afd57c memory.kmem.max_usage_in_bytes memory.memsw.failcnt memory.stat cgroup.clone_children memory.kmem.slabinfo memory.memsw.limit_in_bytes memory.swappiness cgroup.event_control memory.kmem.tcp.failcnt memory.memsw.max_usage_in_bytes memory.usage_in_bytes cgroup.procs memory.kmem.tcp.limit_in_bytes memory.memsw.usage_in_bytes memory.use_hierarchy ecb8d7dac939ff1c45713928a406721f078fdce87965c04f63291b8ef4172717 memory.kmem.tcp.max_usage_in_bytes memory.move_charge_at_immigrate notify_on_release memory.failcnt memory.kmem.tcp.usage_in_bytes memory.numa_stat tasks memory.force_empty memory.kmem.usage_in_bytes memory.oom_control memory.kmem.failcnt memory.limit_in_bytes memory.pressure_level memory.kmem.limit_in_bytes memory.max_usage_in_bytes memory.soft_limit_in_bytes 复制代码
About The Author
bjmayor
程序员，码农，php,python,ios,android,go，产品经理，创业。