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