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（翻译：钟最龙 校对：李颖杰）

来自：http://dockone.io/article/356