本文讲的是Docker容器：更小不一定更好， 【编者的话】按正常逻辑来说，我们应该选择体积较小的Docker容器。然而事实是，体积小却并不一定能带来性能上的优势。本文将介绍一个使用了一个体积稍大一点的容器，从而将性能提高30倍以上的例子。

按道理来说，我们应该选择体积较小的Docker容器。然而事实是，体积小却并不一定能带来性能上的优势。本文将介绍一个使用了一个体积稍大一点的容器，从而将性能提高30倍以上的例子。

摘要

当使用 grep 来处理大量的数据的时候， busybox 中带的 grep 速度慢的让人痛苦。 解决之道是向容器添加一个（真正的） grep 。

背景

在 一文中，我试图找到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 ";dateSun Apr 19 14:25:54 GMT 201519real    1m 4.21suser    3m 57.52ssys 0m 3.52sSun 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/grep501101 lrwxrwxrwx    1 root     root            12 Mar  6 13:27 /bin/grep -> /bin/busybox

从体积小来看，这通常确实是一个很好的选择。然而，其携带的 grep 要慢许多。突然我好像柳暗花明，我决定安装下 grep ：

/opt/smiles # apk search grepngrep-1.45-r1grep-doc-2.20-r1grep-2.20-r1/opt/smiles # apk --update add grepfetch 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.triggerOK: 6 MiB in 18 packages/opt/smiles # which grep/usr/bin/grep/opt/smiles # ls -li /usr/bin/grep66417 -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 ";dateSun Apr 19 14:30:35 GMT 201519real    0m 1.81suser    0m 4.39ssys 0m 2.38sSun Apr 19 14:30:36 GMT 2015

吸取到的教训

这件事情再次印证了对常识进行质疑的必要性。在这里的常识是，更小体积的容器那绝对是更好。我相信了体积更小，更轻量的容器是一个好的实践，应该遵循。然而，验证结果证明更小不一定更好。

我也有在下载一个容器之前检查Dockerfile的习惯，在这里这却不够。这也同时提醒我，在使用容器之前需要清楚里面运行的是什么。

原文链接：（翻译：钟最龙 校对：李颖杰）

原文发布时间为：2015-05-06

本文作者：kurtzhong 

本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。

原文标题：Docker容器：更小不一定更好