docker客户端拉包逻辑及优化思路
Posted 我爱看明朝
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了docker客户端拉包逻辑及优化思路相关的知识,希望对你有一定的参考价值。
docker客户端拉包逻辑及优化思路
docker pull xxxxxx
Concurrent downloads
By default the Docker daemon will pull three layers of an image at a time. If you are on a low bandwidth connection this may cause timeout issues and you may want to >>lower this via the --max-concurrent-downloads daemon option. See the daemon documentation for more details.
docker pull每次一个镜像默认并发拉3层,如果你的带宽比较小,导致了超时问题,你可以通过调整–max-concurrent-downloads来减少并发数。
local disk store
Docker uses a content-addressable image store, and the image ID is a SHA256 digest covering the image’s configuration and layers. In the example above, debian:jessie and debian:latest have the same image ID because they are actually the same image tagged with different names. Because they are the same image, their layers are stored only once and do not consume extra disk space.
docker镜像是由元数据加层(layer)构成,每一层都有一个sha256,机器上同sha256只会保存一份,也就是说的当两个镜像有一层是相同的,相同的这一层只会请求一次网络下载。
docker pull的运行原理
执行docker pull从远程仓库拉镜像的docker client的步骤是:
1.从远程仓库获取到manifests各个层的disgest(sha256)
2.在本地机器搜索是否sha256已经存在
3.如sha256在本地机器不存在,则从远程仓库拉取sha256
4.同一个镜像并发拉的层数受–max-concurrent-downloads这个参数控制(默认一个镜像并发拉3层)
5.下载完成后,进行extracting解压合并所有层生成镜像
从上面我们可以看到,拉取镜像的速度受一下因素影响:
1.本地机器已有的镜像数(镜像数、层数),如果太多,搜索的时候就会耗费很多时间
2.本地机器、远程仓库的带宽
3.本地机器的磁盘IO吞吐量
3.设置的并发数,决定带宽是否充分利用
4.当前机器同时进行pull的镜像数量
5.机器负载,下载成功后解压合并需要耗费CPU负载
优化思路
从上面的原理我们可以看到,镜像下载快慢,受综合因素影响:机器当前存在的镜像数、带宽、CPU、磁盘IO、机器同时docker pull的数量。
docker pull的总数量我们不控制,但是我们可以调整同时拉的数量、带宽极限1000M、磁盘IO也有极限,CPU同样如此。
在我们调整了硬件:
1.带宽1000M
2.CPU、磁盘使用能调动的最大
我们能控制的就是:
1.定时清理本地的镜像(或用完就删除)
2.部署机同时放进的任务数
3.调大–max-concurrent-downloads这个参数,加快单个镜像的拉取速度。
4.增加处理dokcer pull的机器
总结:在资源调动允许范围内磁盘IO、带宽、CPU使用最好的;减少并发拉取镜像的数量,调大单个镜像并发拉取的层数,加快单个任务的吞吐,不是系统雪崩,从而加快所有任务的速度。
调整–max-concurrent-downloads参数
cd /ect/docker
cat daemon.json
"max-concurrent-downloads": 20,
"max-concurrent-uploads": 20
一些分析、跟踪问题使用的命令
//修改daemon.json重启docker服务
**sudo systemctl restart docker**
//查看docker Pull的网络连接 端口:请求远程仓库的端口
netstat -apn | grep 端口
//example
netstat -apn | grep 8443
//查看端口的网络连接数
netstat -apn | grep 端口 | wc -l
//example
netstat -apn | grep 8443 | wc -l
//查看docker pull的进程
ps -ef|grep 'docker pull'
//删除本地带有 8443的镜像
docker rmi --force `docker images | grep 8443 | awk 'print $3'`
//查看docker client的日志
tail -f /var/log/messages |grep dockerd
测试技术指标
机器:8C4核, 1000M带宽
max-concurrent-downloads=50
“max-concurrent-downloads”: 50,
“max-concurrent-uploads”: 50,
调到50, 带宽每秒可以到30M左右,峰值50M,连接数峰值78,机器负载13,磁盘Iod峰值50M,平均30M左右 可同时拉11个镜像,但是extracting会很慢
max-concurrent-downloads=30
“max-concurrent-downloads”: 30,
“max-concurrent-uploads”: 30,
调到30, 带宽每秒可以到30M左右,峰值50M,连接数峰值46,连接数稳定值30,机器负载5分钟高峰12,平均10分钟负载9,磁盘Iod峰值60M,平均30M左右 可同时拉11个镜像,但是extracting会很慢
会存在docker client timeout
max-concurrent-downloads=20
“max-concurrent-downloads”: 20,
“max-concurrent-uploads”: 20
并行7个任务 + 1个手拉
调到20, 带宽每秒可以到20M左右,峰值26M;连接数峰值30,连接数稳定值20;机器负载5分钟高峰15,平均10分钟负载8,磁盘Iod峰值50M,平均30M左右 可同时拉8个镜像,但是extracting会很慢
extracting:占用大量负载,因为是解压合并文件
建议并行6~7个任务,docker pull 是一个占用网络IO、磁盘IO、cpu负载的综合型操作
其他一些参数
--max-concurrent-downloads int Set the max concurrent downloads for each pull (default 3)
--max-concurrent-uploads int Set the max concurrent uploads for each push (default 5)
--max-download-attempts int Set the max download attempts for each pull (default 5)
相关参考
https://docs.docker.com/engine/reference/commandline/dockerd/
https://www.educba.com/docker-pull/
以上是关于docker客户端拉包逻辑及优化思路的主要内容,如果未能解决你的问题,请参考以下文章