如何查找占用资源最多的Docker容器及dockerd高CPU占用问题排查

• 日志相关异常：默认json-file日志驱动下，容器的日志写入、序列化、轮转全部由dockerd进程负责，这部分开销不会统计到容器的CPU占用中。如果存在大量容器瞬时输出日志、日志未配置轮转导致单日志文件过大，都可能触发dockerd CPU飙升。可以先查看/var/lib/docker/containers/下各容器的日志体积，临时清理验证可执行docker system prune -af。
• 存储驱动适配问题：使用overlay2以外的老旧存储驱动（如aufs、loop-lvm模式的devicemapper），或者频繁创建删除大量小镜像/容器导致存储层碎片化严重时，dockerd处理文件系统元数据、镜像层合并的开销会大幅升高，这部分负载也不会体现在容器统计里。可以执行docker info | grep 'Storage Driver'确认当前存储驱动版本。
• daemon内部状态异常：存在僵尸容器残留、未正常释放的挂载点、大量未处理的API请求堆积时，dockerd可能进入重试死循环，导致CPU占满。可以执行kill -SIGUSR1 $(pidof dockerd)让dockerd输出性能排查报告到/var/run/docker/目录定位问题，临时恢复可执行systemctl reload docker平滑重启daemon。
• cgroup驱动不匹配：如果docker配置的cgroup驱动和宿主机systemd使用的cgroup驱动不一致，dockerd会持续尝试同步cgroup状态产生无效开销。可以执行docker info | grep 'Cgroup Driver'查看docker的cgroup配置，和cat /proc/1/cgroup的宿主机配置做对比。
• 元数据损坏：部分镜像层、容器配置文件损坏时，dockerd会持续重试读取损坏的元数据，也会引发高CPU占用，通常伴随docker命令响应变慢的现象。

内容的提问来源于stack exchange，提问作者ark