详解Docker cpu限制分析
作者：ARunningPig
字体：[ ] 类型：转载 时间：
本篇文章主要介绍了Docker cpu限制分析，小编觉得挺不错的，现在分享给大家，也给大家做个参考。一起跟随小编过来看看吧
本文测试了，Docker容器限制cpu资源使用的几个配置参数。分别使用top和dstat命令分析了资源占有情况。
package main
func main() {
cpunum := flag.Int("cpunum", 0, "cpunum")
flag.Parse()
fmt.Println("cpunum:", *cpunum)
runtime.GOMAXPROCS(*cpunum)
for i := 0; i & *cpunum - 1; i++ {
go func() {
制作了一个测试cpu占用的镜像，镜像默认占满1个核心
FROM busybox
COPY ./full_cpu /full_cpu
RUN chmod +x /full_cpu
ENTRYPOINT ["/full_cpu", "-cpunum"]
docker build -t fangfenghua/cpuuseset .
docker push fangfenghua/cpuuseset
docker info
Default Runtime: runc
Security Options: seccomp
Kernel Version: 3.10.0-229.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
Total Memory: 993.3 MiB
Name: localhost.localdomain
ID: TU6M:E6WM:PZDN:ULJX:EWKS:
docker run -it --rm=true fangfenghua/cpuuseset
[root@localhost src]# top
top - 07:23:52 up 1:23, 2 users, load average: 0.61, 1.12, 1.04
Tasks: 154 total,
3 running, 145 sleeping,
6 stopped,
%Cpu(s): 18.0 us, 0.1 sy, 0.0 ni, 81.8 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem : 1017144 total,
422120 free,
171676 used,
423348 buff/cache
KiB Swap: 1040380 total, 1040284 free,
688188 avail Mem
SHR S %CPU %MEM
TIME+ COMMAND
20196 root
460 R 101.7 0.1
0:37.56 full_cpu
0:02.60 systemd
0:00.04 kthreadd
0:00.48 ksoftirqd/0
0:00.00 kworker/0:0H
0:00.69 migration/0
docker run -it --rm=true fangfenghua/cpuuseset 4
top - 07:27:17 up 1:27, 2 users, load average: 2.41, 1.47, 1.18
Tasks: 159 total,
3 running, 145 sleeping, 11 stopped,
%Cpu(s): 99.6 us, 0.2 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
KiB Mem : 1017144 total,
402508 free,
190908 used,
423728 buff/cache
KiB Swap: 1040380 total, 1040284 free,
668608 avail Mem
SHR S %CPU %MEM
TIME+ COMMAND
20935 root
452 R 400.0 0.1
0:55.80 full_cpu
0:02.88 systemd
0:00.04 kthreadd
在Linux 系统上，可以用来限制docker容器资源占用的参数有：
--cpu-period int&&&&&&&&&&&&& Limit CPU CFS (Completely Fair Scheduler) period
--cpu-quota int&&&&&&&&&&&&&& Limit CPU CFS (Completely Fair Scheduler) quota
-c, --cpu-shares int&&&&&&&&&&&&& CPU shares (relative weight)
&--cpuset-cpus string&&&&&&&&& CPUs in which to allow execution (0-3, 0,1)
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设置为.2秒）。当然，在多核情况下，如果允许容器进程需要完全占用两个CPU，则可以将cpu-period设置为100000（即0.1秒），cpu-quota设置为.2秒）。
使用本文制作的容器镜像来测试，cpu-period和cpu-quota两个参数吧。
在本文使用的4核心系统中，如果希望cpuusetest占满两个核心，在如何配置呢？从上文的分析中可以看到，如果将cpu-period设置为100000，那么期望占满4个核心，则需要将cpu-quota设置为4＊100000，期望占满一个核心则可设置为2＊100000。下面就测试一下吧：
docker run --name cpuuse -d --cpu-period=100000 --cpu-quota=200000 fangfenghua/cpuusetest 4
top - 07:46:31 up 1:46, 2 users, load average: 0.16, 0.21, 0.51
Tasks: 168 total,
2 running, 142 sleeping, 24 stopped,
%Cpu(s): 47.8 us, 0.1 sy, 0.0 ni, 51.9 id, 0.1 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem : 1017144 total,
364724 free,
227816 used,
424604 buff/cache
KiB Swap: 1040380 total, 1040284 free,
631052 avail Mem
SHR S %CPU %MEM
TIME+ COMMAND
21766 root
464 R 193.3 0.1
1:00.37 full_cpu
0:03.13 systemd
0:00.05 kthreadd
0:00.52 ksoftir
top - 07:47:17 up 1:47, 2 users, load average: 0.47, 0.26, 0.51
Tasks: 172 total,
3 running, 144 sleeping, 25 stopped,
%Cpu(s): 99.6 us, 0.1 sy, 0.0 ni, 0.3 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem : 1017144 total,
358760 free,
233292 used,
425092 buff/cache
KiB Swap: 1040380 total, 1040284 free,
625180 avail Mem
docker run --name cpuuse -d --cpu-period=100000 --cpu-quota=400000 fangfenghua/cpuusetest 4
SHR S %CPU %MEM
TIME+ COMMAND
21976 root
456 R 398.3 0.1
0:16.81 full_cpu
21297 root
0:00.08 kworker/0:2
0:03.19 systemd
0:00.05 kthreadd
使用上述两个参数可以，设置cpu的精确控制。还有一个参数cpu-share，是个相对值。假如设置A容器cpu－share为1536，设置B容器为512。那么，在容器B启动前，cpu占用情况为是什么呢？
top - 07:56:10 up 1:56, 2 users, load average: 0.75, 0.36, 0.50
Tasks: 153 total,
3 running, 140 sleeping, 10 stopped,
%Cpu(s): 99.7 us, 0.1 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
KiB Mem : 1017144 total,
436300 free,
155616 used,
425228 buff/cache
KiB Swap: 1040380 total, 1040284 free,
703544 avail Mem
SHR S %CPU %MEM
TIME+ COMMAND
22216 root
456 R 399.3 0.1
0:55.03 full_cpu
0:03.29 systemd
0:00.05 kthreadd
0:00.54 ksoftirqd/0
启动容器B:
top - 07:57:09 up 1:57, 2 users, load average: 3.55, 1.16, 0.76
Tasks: 162 total,
4 running, 148 sleeping, 10 stopped,
%Cpu(s): 99.6 us, 0.2 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
KiB Mem : 1017144 total,
428772 free,
158304 used,
430068 buff/cache
KiB Swap: 1040380 total, 1040284 free,
700444 avail Mem
SHR S %CPU %MEM
TIME+ COMMAND
22216 root
456 R 305.7 0.1
4:40.78 full_cpu
22336 root
460 R 95.3 0.1
0:09.02 full_cpu
0:03.31 systemd
从上述测试结果不难看出。设置相对数值时，容器B启动之前，容器A仍然占满了cpu，而容器B启动后则，容器占3／4，容器B占1／4。
还有一个参数cpu-sets，指定容器使用的核心。使用上述测试容器测试，指定容器使用0，3核心：
docker run --name cpuuse -d --cpuset-cpus=0,3 fangfenghua/cpuusetest 4
0,3核心占用率：
[root@localhost src]# dstat -c -C 0,3
-------cpu0-usage--------------cpu3-usage------
usr sys idl wai hiq siq:usr sys idl wai hiq siq
1，2核心占用率：
[root@localhost src]# dstat -c -C 1,2
-------cpu1-usage--------------cpu2-usage------
usr sys idl wai hiq siq:usr sys idl wai hiq siq
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持脚本之家。
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具docker容器访问宿主机
docker从容器里面拷文件到宿主机或从宿主机拷文件到docker容器里面：1、从容器里面拷文件到宿主机？答：在宿主机里面执行以下命令docker cp 容器名：要拷贝的文件在容器里面的路径...docker容器间通过宿主机映射的端口如何通信？
你好，想跟你请教个问题：
现在在同一个宿主机上开了两个docker容器A和B：
通过A调用B的服务，直接使用docker容器自身IP和服务端口是可以访问
通过宿主机映射给B的端口，在浏览器上通过宿主机IP是可以访问B的服务的
通过宿主机给docker容器映射的端口，使用宿主机IP通过A调用B的服务无法访问
这个应该是防火墙的问题，那么应该如何设置呢？
我也遇到了这个问题，您当时是怎么解决的呢？
貌似有第三方工具可以搞，不过可以使用docker内部Ip暂时解决
--- 共有 1 条评论 ---
内部ip太蛋疼了，每次重启一下就变了，你说的第三方工具是啥？
version: "2"
discovery:
image: concur/concur-discovery-server
hostname: discovery
- concur-net
configserver:
image: concur/concur-config-server
hostname: config
- concur-net
- discovery
image: concur/concur-token-service
- concur-net
- discovery
image: concur/concur-partner-service
- concur-net
- discovery
image: concur/concur-client-service
- concur-net
- discovery
image: concur/concur-task-service
- concur-net
- discovery
concur-net:
driver: bridge
这是我做java/springcloud时候用到的，关键字是networks，仅供参考Docker 监控实战
发表于 17:28|
摘要：如今，越来越多的公司开始使用 Docker 了，2 / 3 的公司在尝试了 Docker 后最终使用了它。同时，研究发现主机数量越多的公司，越早使用 Docker。
如今，越来越多的公司开始使用 Docker 了，现在来给大家看几组数据：2 / 3 的公司在尝试了 Docker 后最终使用了它，也就是说 Docker 的转化率达到了 67%，而且转化时长也控制在 60 天内。
越大型的公司越早开始使用 Docker研究发现主机数量越多的公司，越早开始使用 Docker。而主机数量多，在这个研究里就默认等同于是大型公司了。
Docker 优势那为什么 Docker 越来越火呢？一谈起 Docker 总是会跟着让人联想到轻量这个词，甚至会有一种通过 Docker 启动一个服务会节省很多资源的错觉。然而
Docker 的「轻」也只是相对于传统虚拟机而已。传统虚拟机和 Docker 的对比如图：
从图中可以看出 Docker 和 虚拟机的差异，虚拟机的 Guest OS 和 Hypervisor 层在 Docker 中被 Docker
Engine 层所替代，Docker 有着比虚拟机更少的抽象层。
由于 Docker 不需要通过 Hypervisor 层实现硬件资源虚拟化，运行在 Docker 容器上的程序直接使用实际物理机的硬件资源。因此在
CPU、内存利用率上 Docker 略胜一筹。
Docker 利用的是宿主机的内核，而不需要 Guest OS，因此，当新建一个容器时，Docker 不需要和虚拟机一样重新加载一个操作系统内核，因此新建一个
Docker 容器只需要几秒钟。
总结一下 Docker 容器相对于 VM 有以下几个优势：启动速度快、资源利用率高、性能开销小。Docker 监控方案
那么，既然 Docker 这么火，Docker 监控是不是也该提上日程？或许具体问题要具体分析，但是似乎大家都在使用开源的监控方案，来解决
Docker监控的问题。
就拿腾讯游戏来说吧，我们看看尹烨（腾讯互娱运营部高级工程师，&&）怎么说：容器的监控问题也花了我们很多精力。监控、告警是运营系统最核心的功能之一，腾讯内部有一套很成熟的监控告警平台，而且开发运维同学已经习惯这套平台，如果我们针对 Docker 容器再开发一个监控告警平台，会花费很多精力，而且没有太大的意义。所以，我们尽量去兼容公司现有的监控告警平台。每个容器内部会运行一个代理，从 /proc 下面获取 CPU、内存、IO 的信息，然后上报公司的监控告警平台。但是，默认情况下，容器内部的 proc 显示的是 Host 信息，我们需要用 Host 上 cgroup 中的统计信息来覆盖容器内部的部分 proc 信息。我们基于开源的 lxcfs，做了一些改造实现了这个需求。
这些解决方案都是基于开源系统来实现的，当然，我们也会把我们自己觉得有意义的修改回馈给社区，我们给 Docker、Kubernetes 和 lxcfs 等开源项目贡献了一些 patch。融入社区，与社区共同发展，这是一件很有意义的事情。在没有专业运维团队来监控 Docker 的情况下，并且还想加快 Docker 监控的进程，该怎么办呢？
为了能够更精确的分配每个容器能使用的资源，我们想要实时获取容器运行时使用资源的情况，怎样对 Docker 上的应用进行监控呢？Docker
的结构会不会加大监控难度？
我们都了解， container 相当于小型 host，可以说存在于 hosts 与应用之间的监控盲区，无论是传统的基础组件监控还是应用性能监控的方式，都很难有效地监控
Docker。了解了一下现有的 Docker 相关监测 App 和服务，包括简单的开源工具和复杂的企业整体解决方案，下面列举其中的几种作为参考：
1. cAdvisor谷歌的 container introspection 解决方案是 cAdvisor，这是一个 Docker 容器内封装的工具，能够采集、处理和导出运行中的容器的数据。通过它可以看到
CPU 的使用率、内存使用率、网络吞吐量以及磁盘空间利用率等。同时，你还可以通过点击在网页顶部的 Docker Containers 链接，选择某个容器来详细了解它的使用情况。cAdvisor
部署和使用简单，但它只可以监视在同一个 host 上运行的容器，对多节点部署不是太管用。
2. Cloud Insight在我们列举的几个监控 Docker 的服务或平台中，这是唯一一款国内产品。
支持多种操作系统、云主机、数据库和中间件的监控，原理是在平台服务仪表盘和自定义仪表盘中，采集并处理 Metric，对数据进行聚合与分组等计算，提供曲线图、柱状图等多样化的展现形式。优点是监控的指标很全，简单易用，可以期待一下。
3. ScoutScout 是一款监视服务，并不是一个独立的开源项目。它有大量的插件，除了 Docker 信息还可以吸收其他有关部署的数据。因此 Scout
算是一站式监控系统，无需对系统的各种资源来安装各种不同的监控系统。 Scout 的一个缺点是，它不显示有关每个主机上单独容器的详细信息。此外，每个监控的主机十美元这样略微昂贵的价格也是是否选择
Scout 作为监控服务的一个考虑因素，如果运行一个有多台主机的超大部署，成本会比较高。
4. SematextSematext 也是一款付费监控解决方案，计划收费方案是3.5美分/小时。同样也支持
，还包括对容器级事件的监测（停止、开始等等）和管理容器产生的日志。
5. PrometheusPrometheus 由 SoundCloud 发明，适合于监控基于容器的基础架构。支持监控容器的资源和运行特性，支持多维度查询，能聚合 Docker
监控数据。
Docker 监控实践数据的聚合&分组，是运维2.0时代的重头戏，因此我们重点选取其中比较有这个方面代表性的两个监控方案来看看具体的 Docker 监控过程。
先借鉴「Monitor Docker Containers with Prometheus](http://5pi.de//monitor-docker-container」一文中的介绍，来说说这套开源的 Docker 监控方案：；而此篇文字的原文地址：。
Prometheus 由 SoundCloud 发明，可用于监控基于容器的基础架构。Prometheus 特点是高维度数据模型，时间序列是通过一个度量值名字和一套键值对识别。灵活的查询语言允许查询和绘制数据。它采用了先进的度量标准类型像汇总（summaries），从指定时间跨度的总数构建比率或者是在任何异常的时候报警并且没有任何依赖，中断期间使它成为一个可靠的系统进行调试。
Prometheus 支持维度数据，你可以拥有全局和简单的指标名像&container_memory_usage_bytes&，使用多个维度来标识你服务的指定实例。
可以创建一个简单的&container-exporter&来收集 Docker 容器的指标以及输出给
Prometheus 来消费。这个输出器使用容器的名字，id 和 镜像作为维度。额外的&per-exporter&维度可以在&prometheus.conf&中设置。
如果你使用指标名字直接作为一个查询表达式，它将返回有这个使用这个指标名字作为标签的所有时间序列。container_memory_usage_bytes{env="prod",id="23f731ee29ae12fef1ef6726e2fce60e5e3cb47e3c7a",instance="http://1.2.3.4:9088/metrics",job="container-exporter",name="haproxy-exporter-int",image="prom/haproxy-exporter:latest"}
container_memory_usage_bytes{env="prod",id="57690ddfd3bb954d59b2d9dcdfbe999bcedf8c",instance="http://1.2.3.5:9088/metrics",job="container-exporter",name="haproxy-exporter",image="prom/haproxy-exporter:latest"}
container_memory_usage_bytes{env="prod",id="907ac267ebbe4ea6fd7bf3cb4900adc832a302b4",instance="http://1.2.3.2:9088/metrics",job="container-exporter",name="node-exporter",image="prom/container-exporter:latest"}
如果你运行了许多容器，这个看起来像这样：
为了帮助你使得这数据更有意义，你可以过滤（filter） and/or 聚合（aggregate） 这些指标。
使用 Prometheus 的查询语言，你可以对你想的任何维度的数据切片和切块。如果你对一个给定名字的所有容器感兴趣，你可以使用一个表达式像&container_memory_usage_bytes{name="consul-server"}，这个将仅仅显示&name == "consul-server"&的时间序列。
像多维度的数据模型，来实现数据聚合、分组、过滤，不单单是 Prometheus。OpenTSDB 和 InfluxDB 这些时间序列数据库和系统监控工具的结合，让系统监控这件事情变得更加的多元。
如果你是阿里云的用户，或者使用过 Zabbix，那么你会明显感受到一个痛点：没有办法对数据做聚合，只能挨个查看主机的性能指标，更不用说有管理的功能。正因为如此我们才对数据聚合&分组抱有极大兴趣。如果想更多地了解数据聚合和分组的相关内容也可以阅读一下这篇文章。
现在我们来对比 Prometheus 和 Cloud Insight 在数据聚合、分组（切片）上的展现效果和功能。
数据聚合根据不同的 Container Name 或 Image Name 对内存使用量或 Memeory Cache 进行聚合。
数据分组（切片)根据不同的 Container Name 或 Image Name 对内存使用量或 Memeory Cache进行分组（切片）。
单方面监控 Docker 可能并不太适合与业务挂钩的应用，当业务量上涨，不单单是 Docker 的负载上升，其他 JVM 指标也能也会出现上升的趋势。如果我们利用
Acme 模拟真实应用环境，再通过 Cloud Insight 进行监控的话，需要新建一个用于此次监控的仪表盘，依次将想要获取的指标统统添加进去。
可以添加以下指标：docker.cpu.user
docker.cpu.sysytem
docker.containers.running
jvm.heap_memory
jvm.non_heap_memory
jvm.gc.cms.count
jvm.heap_memory_max
jvm.gc.parnew.time
应用 Acme 部署在四台 servers 上，我们开启四台 servers, 然后用 JMeter 给应用加压。随着时间 JMeter 不断给应用加压，当
users 人数达到 188 时，我们来看一下仪表盘的视图。
根据 JMeter 里的数据，CPU 占用和错误率都有所提升；与此同时，在指标&docker.cpu.user&这幅图中，蓝色的线所代表的
Container CPU 占用率已经超过 50%，逐渐接近 75%，系统剩余的 CPU 资源逐渐下降。
而指标&docker.cpu.system&图中同样可以看到蓝色的那条数据在 18：29 左右出现了一个波峰，代表系统
CPU 资源消耗突然增大。通过这两幅图，我们可以定位到 CPU 占用率过高的 Container ，及时而主动地去了解性能瓶颈，从而优化性能，合理分配资源。
用&jvm.heap_memory&的值去比左图&jvm.heap_memory_max&的值，将能清楚的反映
JVM 堆内存的消耗情况。而&jvm.gc.parnew.time&图中显示了新生代并行 GC
的时间数据。GC 是需要时间和资源的，不好的 GC 会严重影响系统的系能，良好的 GC 是 JVM 高性能的保证。
无法被监控的软件是很危险的，通过解读这张 Docker 仪表盘总览图，我们也许可以了解到 Docker 实时性能状况，精准定位到性能薄弱的环节，从而优化我们的应用。
总结Docker 兼容相比其他的数据库、系统、中间件监控，要复杂一些。由于需要表现不同 Container 的性能消耗，来了解不同应用的运行情况，所以数据的聚合、切片（分组）和过滤，在
Docker 监控中成为了必备功能。
所以推荐大家使用时间序列数据库，或者类似设计逻辑的监控方案，如Prometheus等。而 Docker 单方面的监控，可能不太满足一些大型公司的需求，如果一个工具在监控
Docker 同时能够监控其他组件，那就更好了。国外的 Graphite、Grafana 和 Host Graphite，以及国内的 Cloud
Insight，都是能够让用户将不同数据来源都集中在同一个地方进行展现，大家页可以对比和试用一下。
参考文章：
关于作者：张璐，工程师。 （责编/仲浩）
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章