本文讲的是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（翻译：钟最龙 校对：李颖杰）
原文发布时间为：2015-05-06
本文作者：kurtzhong
本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。
原文标题：Docker容器：更小不一定更好
