Docker 限制容器可用的記憶體

預設情況下容器使用的資源是不受限制的。也就是可以使用主機核心排程器所允許的最大資源。但是在容器的使用過程中，經常需要對容器可以使用的主機資源進行限制，本文介紹如何限制容器可以使用的主機記憶體。

限制容器不能過多的使用主機的記憶體是非常重要的。對於 linux 主機來說，一旦核心檢測到沒有足夠的記憶體可以分配，就會扔出 oome(out of memmory exception)，並開始殺死一些程序用於釋放記憶體空間。糟糕的是任何程序都可能成為核心獵殺的物件，包括 docker daemon 和其它一些重要的程式。更危險的是如果某個支援系統執行的重要程序被乾掉了，整個系統也就宕掉了！這裡我們考慮乙個比較常見的場景，大量的容器把主機的記憶體消耗殆盡，oome 被觸發後系統核心立即開始殺程序釋放記憶體。如果核心殺死的第乙個程序就是 docker daemon 會怎麼樣？結果是所有的容器都不工作了，這是不能接受的！

針對這個問題，docker 嘗試通過調整 docker daemon 的 oom 優先順序來進行緩解。核心在選擇要殺死的程序時會對所有的程序打分，直接殺死得分最高的程序，接著是下乙個。當 docker daemon 的 oom 優先順序被降低後(注意容器程序的 oom 優先順序並沒有被調整)，docker daemon 程序的得分不僅會低於容器程序的得分，還會低於其它一些程序的得分。這樣 docker daemon 程序就安全多了。

我們可以通過下面的指令碼直觀的看一下當前系統中所有程序的得分情況：

#!/bin/bash
for proc in $(find /proc -maxdepth 1 -regex '/proc/[0-9]+'); do
printf "%2d %5d %s\n" \
"$(cat $proc/oom_score)" \
"$(basename $proc)" \
"$(cat $proc/cmdline | tr '\0' ' ' | head -c 50)"
done 2>/dev/null | sort -nr | head -n 40

此指令碼輸出得分最高的 40 個程序，並進行了排序：

第一列顯示程序的得分，mysqld 排到的第一名。顯示為 node server.js 的都是容器程序，排名普遍比較靠前。紅框中的是 docker daemon 程序，非常的靠後，都排到了 sshd 的後面。

有了上面的機制後是否就可以高枕無憂了呢！不是的，docker 的官方文件中一直強調這只是一種緩解的方案，並且為我們提供了一些降低風險的建議：

好了，囉嗦了這麼多，其實就是說：通過限制容器使用的記憶體上限，可以降低主機記憶體耗盡時帶來的各種風險。

為了測試容器的記憶體使用情況，筆者在 ubuntu 的映象中安裝了壓力測試工作 stress，並新建立了映象 u-stress。本文演示用的所有容器都會通過 u-stress 映象建立(本文執行容器的宿主機為 centos7)。下面是建立 u-stress 映象的 dockerfile：

from ubuntu:latest

run apt-get update && \

apt-get install stress

建立映象的命令為：

$ docker build -t u-stress:latest .

在進入繁瑣的設定細節之前我們先完成乙個簡單的用例：限制容器可以使用的最大記憶體為 300m。

-m(--memory=) 選項可以完成這樣的配置：

$ docker run -it -m 300m --memory-swap -1 --name con1 u-stress /bin/bash

下面的 stress 命令會建立乙個程序並通過 malloc 函式分配記憶體：

# stress --vm 1 --vm-bytes 500m

通過 docker stats 命令檢視實際情況：

上面的 docker run 命令中通過 -m 選項限制容器使用的記憶體上限為 300m。同時設定 memory-swap 值為 -1，它表示容器程式使用記憶體的受限，而可以使用的 swap 空間使用不受限制(宿主機有多少 swap 容器就可以使用多少)。

下面我們通過 top 命令來檢視 stress 程序記憶體的實際情況：

上面的截圖中先通過 pgrep 命令查詢 stress 命令相關的程序，程序號比較大的那個是用來消耗記憶體的程序，我們就檢視它的記憶體資訊。virt 是程序虛擬記憶體的大小，所以它應該是 500m。res 為實際分配的物理記憶體數量，我們看到這個值就在 300m 上下浮動。看樣子我們已經成功的限制了容器能夠使用的物理記憶體數量。

強調一下--memory-swap是必須要與--memory一起使用的。

正常情況下， --memory-swap 的值包含容器可用記憶體和可用 swap。所以 --memory="300m" --memory-swap="1g" 的含義為：

容器可以使用 300m 的物理記憶體，並且可以使用 700m(1g -300m) 的 swap。--memory-swap居然是容器可以使用的物理記憶體和可以使用的 swap 之和！

把 --memory-swap 設定為 0 和不設定是一樣的，此時如果設定了 --memory，容器可以使用的 swap 大小為 --memory 值的兩倍。

如果 --memory-swap 的值和 --memory 相同，則容器不能使用 swap。下面的 demo 演示了在沒有 swap 可用的情況下向系統申請大量記憶體的場景：

demo 中容器的物理記憶體被限制在 300m，但是程序卻希望申請到 500m 的物理記憶體。在沒有 swap 可用的情況下，程序直接被 oom kill 了。如果有足夠的 swap，程式至少還可以正常的執行。

我們可以通過 --oom-kill-disable 選項強行阻止 oom kill 的發生，但是筆者認為 oom kill 是一種健康的行為，為什麼要阻止它呢？

通過限制容器可用的物理記憶體，可以避免容器內服務異常導致大量消耗主機記憶體的情況(此時讓容器重啟是較好的策略)，因此可以降低主機記憶體被耗盡帶來的風險。

出處：

Docker 限制容器可用的記憶體

Docker 限制容器可用的記憶體

Docker如何限制容器可用的記憶體

Docker容器記憶體限制

Docker 限制容器可用的記憶體

Docker 限制容器可用的記憶體

Docker如何限制容器可用的記憶體

Docker容器記憶體限制

相關推薦