通常来讲,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
下面的内容,并且在docker之外试了搜索后,我决定是否我该使用一个更快的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的习惯,在这里这却不够。这也同时提醒我,在使用容器之前需要清楚里面运行的是什么。