gpt4 book ai didi

CPU百分比超过100的Docker统计信息

转载 作者:行者123 更新时间:2023-12-04 04:24:08 28 4
gpt4 key购买 nike

我对docker stats命令有疑问,是否有人可以帮助我。我是Docker领域的新手,我想监视Docker容器的cpu使用情况。

该物理机具有8个内核(CPU0 ... CPU7)。我已经创建了一个容器,并使用以下命令将其cpu资源限制为1个核心(CPU0):
docker 运行-itd --cpuset-cpus = 0 -p 8081:8080 binfalse/bives-webapp

我通过从Jmeter发送请求来强调容器,然后通过docker stats命令监视容器的cpu使用情况,该命令为我提供的值大于100%。

我不明白为什么即使仅将一个内核分配给容器,它也提供100%以上的结果!您对原因有任何想法吗?除了容器之外,此cpu值是否还代表某些系统进程的cpu使用情况?

在此先感谢您的帮助。

docker 版本:
客户:
版本:17.06.0-ce
API版本:1.30
Go版本:go1.8.3
Git提交:02c1d87
建成:2017年6月23日星期五21:23:31
操作系统/Arch:linux/amd64

服务器:
版本:17.06.0-ce
API版本:1.30(最低版本1.12)
Go版本:go1.8.3
Git提交:02c1d87
建成:2017年6月23日星期五21:19:04
操作系统/Arch:linux/amd64
实验性:真实

docker 信息结果:
货柜:2
运行:1
已暂停:0
已停止:1
图片:10
服务器版本:17.06.0-ce
存储驱动程序:aufs
根目录:/var/lib/docker/aufs
支持文件系统:extfs
dirs:141
Dirperm1支持:true
记录驱动程序:json-file
Cgroup驱动程序:cgroupfs
外挂程式:
数量:本地
网络:网桥主机ipvlan macvlan空覆盖
日志:awslogs流利的gcplogs gelf记录日志的json文件日志条目splunk syslog
群:不 Activity
运行时:runc
默认运行时:runc
初始化二进制文件:docker-init
容器版本:cfb82a876ecc11b5ca0977d1733adbe58599088a
runc版本:2d41c047c83e09a6d61d464906feb2a2f3c52aa4
初始化版本:949e6fa
安全选项:
装甲兵
seccomp
个人资料:默认
内核版本:4.4.0-98-generic
作业系统:Ubuntu 16.04.2 LTS
操作系统类型:linux
架构:x86_64
处理器:8
总内存:15.56GiB
名称:logti048131
ID:RHOG:IR6N:FVC4:YDI5:A6T4:QA4Y:DDYF:7HZN:AI3L:WVLE:BNHY:6YNV
Docker根目录:/var/lib/docker
Debug模式(客户端):false
Debug模式(服务器):false
注册表:https://index.docker.io/v1/
实验性:真实
不安全的注册表:
127.0.0.0/8
启用实时还原:false

警告:不支持交换限制

最佳答案

在Linux上,cgroup和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就足以导致更多的不准确性。我最好的猜测是所有试图读取统计信息的goroutine中的争用。我不确定这是否会解释Docker显示的不准确程度。我完全错了,或者还有其他问题在加重。

Linux cgroups

每个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中进行了一些转换。

关于CPU百分比超过100的Docker统计信息,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/47401648/

28 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com