我有一个关于docker stats命令的问题，如果有人可以帮助我的话。我是Docker领域的新手，我想监视一个docker容器的cpu使用情况。
物理机有8个核心（CPU0 ... CPU7）。我已经创建了一个容器，并使用以下命令将其cpu资源限制为1个核心（CPU0）： docker run -itd --cpuset-cpus = 0 -p 8081：8080 binfalse / bives-webapp
我通过发送来自Jmeter的请求来强调容器，然后通过docker stats命令监视容器的cpu使用情况，这使得我的值大于100％。
我不明白为什么即使只有一个核心分配给容器，它也会超过100％！你对这个原因有什么看法吗？除了容器之外，此cpu值是否表示某些系统进程的CPU使用率？
提前感谢您的帮助。
docker version： 客户： 版本：17.06.0-ce API版本：1.30 转到版本：go1.8.3 Git commit：02c1d87 建造：2017年6月23日星期五21:23:31 OS / Arch：linux / amd64
服务器： 版本：17.06.0-ce API版本：1.30（最低版本1.12） 转到版本：go1.8.3 Git commit：02c1d87 建造：2017年6月23日星期五21:19:04 OS / Arch：linux / amd64 实验：真的
码头信息结果 容器：2 跑步：1 暂停：0 停了下来：1 图片：10 服务器版本：17.06.0-ce 存储驱动程序：aufs Root Dir：/ var / lib / docker / aufs 支持文件系统：extfs Dirs：141 Dirperm1支持：true 记录驱动程序：json-file Cgroup驱动程序：cgroupfs 插件： 卷：本地 网络：桥接主机ipvlan macvlan null覆盖 日志：awslogs流利的gcplogs gelf journald json-file logentries splunk syslog Swarm：不活跃 运行时：runc 默认运行时：runc Init Binary：docker-init containerd版本：cfb82a876ecc11b5ca0977d1733adbe58599088a runc版本：2d41c047c83e09a6d61d464906feb2a2f3c52aa4 init版本：949e6fa 安全选项： AppArmor的 的Seccomp 简介：默认 内核版本：4.4.0-98-通用 操作系统：Ubuntu 16.04.2 LTS OSType：linux 架构：x86_64 CPU：8 总内存：15.56GiB 名称：logti048131 ID：RHOG：IR6N：FVC4：YDI5：A6T4：QA4Y：DDYF：7HZN：AI3L：WVLE：BNHY：6YNV Docker Root目录：/ var / lib / docker 调试模式（客户端）：false 调试模式（服务器）：false 注册表：https://index.docker.io/v1/ 实验：是的 不安全的注册管理机构： 127.0.0.0/8 实时恢复已启用：false
警告：没有交换限制支持
答案 0 :(得分：1)
在Linux上，cgroups和Docker CPU统计数据处理CPU的“时间片”，即CPU使用的纳秒数。要获得百分比，将“使用时间”的容器cgroup值与/proc/stat的“可用时间”的整体系统值进行比较。
由于存储的“时间片”值是累积的，因此将当前值与先前收集的值进行比较以获得更加瞬时的百分比。我认为这种比较是问题的基础。
docker stats命令实际上为客户端中的此信息做了很多工作。客户端查询所有容器，监视容器启动/停止的事件以及每个正在运行的容器的opens an individual stats stream。这些容器统计信息流用于在流中每次转储统计数据时calculate the percentages。
对于容器统计信息流，Docker守护程序首先收集systems used cpu time。然后它使用libcontainer到read in a containers cgroup files and parse the text into values。这是all the stats data structures。然后将其作为JSON响应发送到客户端进行处理。
我认为至少部分问题源于在不同时间阅读和解析/proc/stat系统信息和容器cgroup统计信息。每次读取容器信息的goroutine都会延迟一点，与系统相比，该样本中包含的纳秒数更多。由于收集过程计划每X秒运行一次，因此下一次读取包括较少的总纳秒，因此值可以在繁忙的系统上反弹，然后返回相同的量，因为第二次没有包含完整的“滴答”样品。
问题会使您运行的容器越多，系统越忙。收集和转发到客户端的统计信息似乎是一个相对较重的过程，只有docker stats具有大量容器足以导致更多不准确。我最好的猜测是goroutines中的争论都在试图读取统计数据。我不确定这会导致Docker显示的不准确程度。我要么完全错了，要么还有其他问题。
每个Docker容器使用情况都在cgroup中进行跟踪。可以通过cgroup文件系统查看CPU记帐信息：
→ find /sys/fs/cgroup/cpuacct/docker -type d
/sys/fs/cgroup/cpuacct/docker
/sys/fs/cgroup/cpuacct/docker/f0478406663bb57d597d4a63a031fc2e841de279a6f02d206b27eb481913c0ec
/sys/fs/cgroup/cpuacct/docker/5ac4753f955acbdf38beccbcc273f954489b2a00049617fdb0f9da6865707717
/sys/fs/cgroup/cpuacct/docker/a4e00d69819a15602cbfb4f86028a4175e16415ab9e2e9a9989fafa35bdb2edf
/sys/fs/cgroup/cpuacct/docker/af00983b1432d9ffa6de248cf154a1f1b88e6b9bbebb7da2485d94a38f9e7e15
→ cd /sys/fs/cgroup/cpuacct/docker/f0478406663bb57d597d4a63a031fc2e841de279a6f02d206b27eb481913c0ec
→ ls -l
total 0
-rw-r--r-- 1 root root 0 Nov 20 22:31 cgroup.clone_children
-rw-r--r-- 1 root root 0 Nov 20 04:35 cgroup.procs
-r--r--r-- 1 root root 0 Nov 20 21:51 cpuacct.stat
-rw-r--r-- 1 root root 0 Nov 20 21:51 cpuacct.usage
-r--r--r-- 1 root root 0 Nov 20 22:31 cpuacct.usage_all
-r--r--r-- 1 root root 0 Nov 20 21:51 cpuacct.usage_percpu
-r--r--r-- 1 root root 0 Nov 20 22:31 cpuacct.usage_percpu_sys
-r--r--r-- 1 root root 0 Nov 20 22:31 cpuacct.usage_percpu_user
-r--r--r-- 1 root root 0 Nov 20 22:31 cpuacct.usage_sys
-r--r--r-- 1 root root 0 Nov 20 22:31 cpuacct.usage_user
-rw-r--r-- 1 root root 0 Nov 20 22:31 notify_on_release
-rw-r--r-- 1 root root 0 Nov 20 22:31 tasks
→ cat cpuacct.usage_percpu
3625488147 6265485043 6504277830
每个值是该CPU上以纳秒为单位的累计使用量。
→ grep -w ^cpu /proc/stat
cpu 475761 0 10945 582794 2772 0 159 0 0 0
Values here are USER_HZ == 1/100秒，所以在Docker中进行一些转换。