Docker容器:更小不一定更好
2023-09-27 14:27:26 时间
本文讲的是Docker容器:更小不一定更好,【编者的话】按正常逻辑来说,我们应该选择体积较小的Docker容器。然而事实是,体积小却并不一定能带来性能上的优势。本文将介绍一个使用了一个体积稍大一点的容器,从而将性能提高30倍以上的例子。
按道理来说,我们应该选择体积较小的Docker容器。然而事实是,体积小却并不一定能带来性能上的优势。本文将介绍一个使用了一个体积稍大一点的容器,从而将性能提高30倍以上的例子。
摘要 当使用grep来处理大量的数据的时候,busybox中带的grep速度慢的让人痛苦。 解决之道是向容器添加一个(真正的)grep。
背景 在『Raspberry Pi中实现简单的亚结构匹配』一文中,我试图找到Raspberry Pi处理数据的极限。我选择使用亚结构的搜索作为课题,因为其充满挑战,并且是一个展示Pi中并行worker的处理能力的好例子。
我对NIM(_National Institutes of Health_,美国国立卫生研究院)的PubChem Compounds数据库中的数据做了预处理,然后抽取出SIMLES(_Simplified molecular input line entry specification_,简化分子线性输入规范)数据,这是一种描述化学合成物的语言。作为我首次十分不成熟的实现,我用grep来匹配亚结构。我把文件分拆到5个Pi,每个都会处理大约730个文件,约840M的数据,我然后用xargs实现多核并行处理。跑了几次后,所有的数据会被读到缓存中,然后Pi可以在1-2秒内处理完毕,以备实时的搜索。在1300万数据中找出所有含碳的化合物只需要花8-10秒,这相当不可思议。
在找到了解决方法后,我试着将它搬进Docker。
我选择使用voxxit/alpine-rpi来作为基础镜像 - 它相当小,大概只有5M,几乎包含所有需要的东西。但我发现其带的xargs不支持-P选项,因此我添加了xargs:
我测试了下,可是发现性能糟透了。于是我决定打开shell亲自试试,然后做一些优化。这是优化之前的性能:
正常情况下大量的IO操作的性能在跑了几次后会得到改善,系统能缓存下读到的数据。通常,3次循环就能让所有的数据缓存下来。然而,上面的数据并没有得到改善。
经过验证,我发现多核的并发确实是被用到了。
我继续往下探究,检查IO和VM的数据。发现真是糟透了!在这个时候我开始在Google查找Docker是否使用磁盘缓存,看看我是否漏掉了或者多添了某个参数。我确实不相信Docker使用的IO能慢到那种程度,而我一直是一个坚信想法都该去证实一下的人。
在查看了/proc和/sys下面的内容,并且Ddocker之外试了搜索后,我决定是否我该使用一个更快的grep,结果,该容器使用了busybox:
从体积小来看,这通常确实是一个很好的选择。然而,其携带的grep要慢许多。突然我好像柳暗花明,我决定安装下grep:
我然后重新运行测试,对着出来的结果,我高兴的都想出去跑三圈。
吸取到的教训 这件事情再次印证了对常识进行质疑的必要性。在这里的常识是,更小体积的容器那绝对是更好。我相信了体积更小,更轻量的容器是一个好的实践,应该遵循。然而,验证结果证明更小不一定更好。
我也有在下载一个容器之前检查Dockerfile的习惯,在这里这却不够。这也同时提醒我,在使用容器之前需要清楚里面运行的是什么。
原文链接:Docker Containers: Smaller is not always better(翻译:钟最龙 校对:李颖杰)
原文发布时间为:2015-05-06 本文作者:kurtzhong 本文来自云栖社区合作伙伴DockerOne,了解相关信息可以关注DockerOne。 原文标题:Docker容器:更小不一定更好
Docker的容器管理 docker run 等于创建+启动 docker run 镜像名,如果镜像不存在本地,则会在线去下载该镜像。 注意:容器内的进程必须处于前台运行状态,否则容器就会直接退出,自己部署一个容器运行,命令不得后台运行,前台运行即可。 如果容器内,什么事也没做,容器也会挂掉。容器内,必须有一个进程在前台运行。 我们运行nginx基础镜像,没有运行任何程序,因此容器直接挂掉 docker run nginx
容器技术-Docker的优点 当产品运行在内部的虚拟化平台中,如openstack,也就是KVM虚拟化,创建虚拟机,但是不断增加的云端应用,增加了对硬件资源的消耗,不断的创建虚拟机,消耗了大量的硬件资源。 那么如何高效的利用硬件资源实现云服务呢
按道理来说,我们应该选择体积较小的Docker容器。然而事实是,体积小却并不一定能带来性能上的优势。本文将介绍一个使用了一个体积稍大一点的容器,从而将性能提高30倍以上的例子。
摘要 当使用grep来处理大量的数据的时候,busybox中带的grep速度慢的让人痛苦。 解决之道是向容器添加一个(真正的)grep。
背景 在『Raspberry Pi中实现简单的亚结构匹配』一文中,我试图找到Raspberry Pi处理数据的极限。我选择使用亚结构的搜索作为课题,因为其充满挑战,并且是一个展示Pi中并行worker的处理能力的好例子。
我对NIM(_National Institutes of Health_,美国国立卫生研究院)的PubChem Compounds数据库中的数据做了预处理,然后抽取出SIMLES(_Simplified molecular input line entry specification_,简化分子线性输入规范)数据,这是一种描述化学合成物的语言。作为我首次十分不成熟的实现,我用grep来匹配亚结构。我把文件分拆到5个Pi,每个都会处理大约730个文件,约840M的数据,我然后用xargs实现多核并行处理。跑了几次后,所有的数据会被读到缓存中,然后Pi可以在1-2秒内处理完毕,以备实时的搜索。在1300万数据中找出所有含碳的化合物只需要花8-10秒,这相当不可思议。
在找到了解决方法后,我试着将它搬进Docker。
我选择使用voxxit/alpine-rpi来作为基础镜像 - 它相当小,大概只有5M,几乎包含所有需要的东西。但我发现其带的xargs不支持-P选项,因此我添加了xargs:
apk --update add findutils
我测试了下,可是发现性能糟透了。于是我决定打开shell亲自试试,然后做一些优化。这是优化之前的性能:
/opt/smiles # date;time /bin/ash -c " ls | xargs -P 4 -n 50 grep -h C1CCCCC1C=O| wc -l ";date Sun Apr 19 14:25:54 GMT 2015 real 1m 4.21s user 3m 57.52s sys 0m 3.52s Sun Apr 19 14:26:58 GMT 2015
正常情况下大量的IO操作的性能在跑了几次后会得到改善,系统能缓存下读到的数据。通常,3次循环就能让所有的数据缓存下来。然而,上面的数据并没有得到改善。
经过验证,我发现多核的并发确实是被用到了。
我继续往下探究,检查IO和VM的数据。发现真是糟透了!在这个时候我开始在Google查找Docker是否使用磁盘缓存,看看我是否漏掉了或者多添了某个参数。我确实不相信Docker使用的IO能慢到那种程度,而我一直是一个坚信想法都该去证实一下的人。
在查看了/proc和/sys下面的内容,并且Ddocker之外试了搜索后,我决定是否我该使用一个更快的grep,结果,该容器使用了busybox:
/opt/smiles # ls -li /bin/grep 501101 lrwxrwxrwx 1 root root 12 Mar 6 13:27 /bin/grep - /bin/busybox
从体积小来看,这通常确实是一个很好的选择。然而,其携带的grep要慢许多。突然我好像柳暗花明,我决定安装下grep:
/opt/smiles # apk search grep ngrep-1.45-r1 grep-doc-2.20-r1 grep-2.20-r1 /opt/smiles # apk --update add grep fetch http://repos.lax-noc.com/alpine/v3.1/main/armhf/APKINDEX.tar.gz (1/2) Installing pcre (8.36-r1) (2/2) Installing grep (2.20-r1) Executing busybox-1.22.1-r14.trigger OK: 6 MiB in 18 packages /opt/smiles # which grep /usr/bin/grep /opt/smiles # ls -li /usr/bin/grep 66417 -rwxr-xr-x 1 root root 189840 Feb 2 11:05 /usr/bin/grep
我然后重新运行测试,对着出来的结果,我高兴的都想出去跑三圈。
bash /opt/smiles # date;time /bin/ash -c " ls | xargs -P 4 -n 50 grep -h C1CCCCC1C=O| wc -l ";date Sun Apr 19 14:30:35 GMT 2015 real 0m 1.81s user 0m 4.39s sys 0m 2.38s Sun Apr 19 14:30:36 GMT 2015
吸取到的教训 这件事情再次印证了对常识进行质疑的必要性。在这里的常识是,更小体积的容器那绝对是更好。我相信了体积更小,更轻量的容器是一个好的实践,应该遵循。然而,验证结果证明更小不一定更好。
我也有在下载一个容器之前检查Dockerfile的习惯,在这里这却不够。这也同时提醒我,在使用容器之前需要清楚里面运行的是什么。
原文链接:Docker Containers: Smaller is not always better(翻译:钟最龙 校对:李颖杰)
原文发布时间为:2015-05-06 本文作者:kurtzhong 本文来自云栖社区合作伙伴DockerOne,了解相关信息可以关注DockerOne。 原文标题:Docker容器:更小不一定更好
Docker的容器管理 docker run 等于创建+启动 docker run 镜像名,如果镜像不存在本地,则会在线去下载该镜像。 注意:容器内的进程必须处于前台运行状态,否则容器就会直接退出,自己部署一个容器运行,命令不得后台运行,前台运行即可。 如果容器内,什么事也没做,容器也会挂掉。容器内,必须有一个进程在前台运行。 我们运行nginx基础镜像,没有运行任何程序,因此容器直接挂掉 docker run nginx
容器技术-Docker的优点 当产品运行在内部的虚拟化平台中,如openstack,也就是KVM虚拟化,创建虚拟机,但是不断增加的云端应用,增加了对硬件资源的消耗,不断的创建虚拟机,消耗了大量的硬件资源。 那么如何高效的利用硬件资源实现云服务呢
相关文章
- 详解Docker容器运行GUI程序的方法
- 如何通过Docker 进行容器编排
- docker容器的IPV6处理。
- Docker兴起 容器技术大量应用于生产环境
- 学习指南!容器技术docker书
- 快速从入门到精通!docker菜鸟教程linux
- 银行用户眼中的Docker容器技术
- Docker入门(三)使用Docker Compose
- 【Docker】Dockerfile 最佳实践-FROM
- 管理和安装 chart - 每天5分钟玩转 Docker 容器技术(168)
- Readiness 探测 - 每天5分钟玩转 Docker 容器技术(144)
- 准备 overlay 网络实验环境 - 每天5分钟玩转 Docker 容器技术(49)
- 创建 Machine - 每天5分钟玩转 Docker 容器技术(46)
- CentOS7开启docker远程访问
- 【Docker】Docker管理平台 Rancher ---- 你应该学学Rancher是怎么做容器的管理的
- Docker(4)- Docker 命令大全
- Swoft 新手向教程 - 通过 Docker 搭建一个开发环境
- docker之容器日志存储位置及把运行日志记录至文件
- 基于微服务和Docker容器技术的PaaS云平台架构设计
- Spring Boot与Docker(一):微服务架构和容器化概述
- Docker应该标准化吗?——其他项目之鉴
- 如何在外部驱动器上存储 Docker 映像和容器
- 如何清除运行 Docker 容器的日志
- 如何在 Docker 容器中运行 MongoDB
- docker 设置容器总是重启,重启策略(记录)
- Docker 基础技术:Linux Namespace(下)