专注于Docker、Container等技术的交流和分享
挖掘最有价值的资讯动态、教程、国内外优秀资源

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

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
19
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
19
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(翻译:钟最龙 校对:李颖杰)

文章转自DockOne,点击查看原文

鲸鱼云公众号:dockercloud

鲸鱼云公众号

转载请加上原文链接和本文链接:鲸鱼云 » Docker容器:更小不一定更好

分享到:更多 ()

评论 抢沙发

评论前必须登录!