单节点Docker Swarm集群中docker build极慢的问题排查咨询

这种单节点Swarm下docker build速度异常的问题我碰到过不少，结合你的环境配置，咱们一步步来排查定位：

单节点Swarm理论上不会直接影响本地构建，但集群的后台进程或服务可能抢占资源：

• 临时退出Swarm模式测试：执行docker swarm leave --force，然后重新运行docker build。如果速度明显恢复，那问题大概率和Swarm的服务/后台组件有关；如果还是慢，就排除Swarm的直接影响，继续往下查。

你的i7+16G配置足够，但22个Swarm服务可能在后台悄悄消耗资源：

• 实时监控资源占用：
  • 用htop查看CPU使用率，有没有Docker相关进程（dockerd、containerd、各服务容器）占满核心；
  • 用free -h确认内存是否被耗尽（如果内存不足会触发swap，速度骤降）；
  • 用iostat -x 1查看磁盘IO：重点看%util指标，如果HDD的这个数值长期接近100%，磁盘就是绝对瓶颈——哪怕是缓存的RUN命令，也可能涉及镜像层的元数据校验读写。
• 检查是否有异常服务：比如某个服务在疯狂写入日志、执行高频健康检查，抢占了磁盘IO或CPU。

你提到是SSD/HDD混合存储，这很可能是关键：

• 确认Docker根目录位置：执行docker info | grep "Docker Root Dir"，看看镜像存储目录是在SSD还是HDD上。如果在HDD上，哪怕是缓存操作，读写速度也会远低于SSD，建议把Docker根目录迁移到SSD（需要修改/etc/docker/daemon.json并重启dockerd）。
• 检查存储驱动：执行docker info | grep "Storage Driver"，18.04-ce默认应该是overlay2，如果是aufs或其他旧驱动，换成overlay2能显著提升镜像层读写性能。
• 清理存储碎片：执行docker system prune -a，清理无用的镜像、容器、卷和网络——大量旧镜像层会导致存储碎片化，拖慢读写速度。

即使是缓存的命令，也可能因为校验步骤变慢：

• 开启详细构建日志：用docker build --progress=plain执行构建，仔细观察每一步的耗时，看是缓存校验卡住，还是命令实际执行慢。比如缓存的RUN chmod理论上应该直接跳过，但如果存储层读取元数据慢，就会卡在校验环节。
• 对比缓存与非缓存构建：执行docker build --no-cache，看耗时和带缓存的构建差异。如果非缓存更慢，说明是命令执行本身的问题；如果缓存校验耗时占比高，还是存储层的锅。

如果退出Swarm后构建速度恢复，那要重点排查22个服务：

• 检查服务资源限制：用docker service inspect <service-name>查看每个服务的CPU/内存限制，有没有服务没设限制，导致抢占了构建时的资源。
• 暂停非核心服务测试：逐个执行docker service scale <service-name>=0，逐步减少运行的服务数量，看构建速度是否提升，定位到是哪个服务在争抢资源。
• 检查Swarm后台任务：比如服务的滚动更新、健康检查频率、日志收集配置——高频健康检查或大日志量都会持续占用磁盘IO。

你的Docker和内核版本都比较老旧，存在性能优化空间：

• 内核升级：4.15.x对overlay2的支持不如5.x系列完善，比如缺乏部分存储优化特性，升级到5.x稳定版（注意备份数据）可能提升存储性能。
• Docker版本升级：18.04-ce已停止维护，新版本（比如20.10.x）在构建缓存、存储性能上有大量优化，还支持BuildKit构建引擎——开启方式：执行export DOCKER_BUILDKIT=1后再运行docker build，能大幅提升构建速度。

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