默認(rèn)情況下容器使用的資源是不受限制的。也就是可以使用主機內(nèi)核調(diào)度器所允許的最大資源。但是在容器的使用過程中，經(jīng)常需要對容器可以使用的主機資源進行限制，本文介紹如何限制容器可以使用的主機內(nèi)存。

為什么要限制容器對內(nèi)存的使用？

限制容器不能過多的使用主機的內(nèi)存是非常重要的。對于 linux 主機來說，一旦內(nèi)核檢測到?jīng)]有足夠的內(nèi)存可以分配，就會扔出 OOME(Out Of Memmory Exception)，并開始?xì)⑺酪恍┻M程用于釋放內(nèi)存空間。糟糕的是任何進程都可能成為內(nèi)核獵殺的對象，包括 docker daemon 和其它一些重要的程序。更危險的是如果某個支持系統(tǒng)運行的重要進程被干掉了，整個系統(tǒng)也就宕掉了！這里我們考慮一個比較常見的場景，大量的容器把主機的內(nèi)存消耗殆盡，OOME 被觸發(fā)后系統(tǒng)內(nèi)核立即開始?xì)⑦M程釋放內(nèi)存。如果內(nèi)核殺死的第一個進程就是 docker daemon 會怎么樣？結(jié)果是所有的容器都不工作了，這是不能接受的！

針對這個問題，docker 嘗試通過調(diào)整 docker daemon 的 OOM 優(yōu)先級來進行緩解。內(nèi)核在選擇要殺死的進程時會對所有的進程打分，直接殺死得分最高的進程，接著是下一個。當(dāng) docker daemon 的 OOM 優(yōu)先級被降低后(注意容器進程的 OOM 優(yōu)先級并沒有被調(diào)整)，docker daemon 進程的得分不僅會低于容器進程的得分，還會低于其它一些進程的得分。這樣 docker daemon 進程就安全多了。

我們可以通過下面的腳本直觀的看一下當(dāng)前系統(tǒng)中所有進程的得分情況：

#!/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 的官方文檔中一直強調(diào)這只是一種緩解的方案，并且為我們提供了一些降低風(fēng)險的建議：

• 通過測試掌握應(yīng)用對內(nèi)存的需求
• 保證運行容器的主機有重組的內(nèi)存
• 限制容器可以使用的內(nèi)存
• 為主機配置 swap
  

好了，啰嗦了這么多，其實就是說：通過限制容器使用的內(nèi)存上限，可以降低主機內(nèi)存耗盡時帶來的各種風(fēng)險。

壓力測試工具 stress

為了測試容器的內(nèi)存使用情況，筆者在 ubuntu 的鏡像中安裝了壓力測試工作 stress，并新創(chuàng)建了鏡像 u-stress。本文演示用的所有容器都會通過 u-stress 鏡像創(chuàng)建(本文運行容器的宿主機為 CentOS7)。下面是創(chuàng)建 u-stress 鏡像的 Dockerfile：

FROM ubuntu:latest
RUN apt-get update && \
  apt-get install stress

創(chuàng)建鏡像的命令為：

$ docker build -t u-stress:latest .

限制內(nèi)存使用上限

在進入繁瑣的設(shè)置細(xì)節(jié)之前我們先完成一個簡單的用例：限制容器可以使用的最大內(nèi)存為 300M。
-m(--memory=) 選項可以完成這樣的配置：

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

下面的 stress 命令會創(chuàng)建一個進程并通過 malloc 函數(shù)分配內(nèi)存：

# stress --vm 1 --vm-bytes 500M

通過 docker stats 命令查看實際情況：

上面的 docker run 命令中通過 -m 選項限制容器使用的內(nèi)存上限為 300M。同時設(shè)置 memory-swap 值為 -1，它表示容器程序使用內(nèi)存的受限，而可以使用的 swap 空間使用不受限制(宿主機有多少 swap 容器就可以使用多少)。
下面我們通過 top 命令來查看 stress 進程內(nèi)存的實際情況：

上面的截圖中先通過 pgrep 命令查詢 stress 命令相關(guān)的進程，進程號比較大的那個是用來消耗內(nèi)存的進程，我們就查看它的內(nèi)存信息。VIRT 是進程虛擬內(nèi)存的大小，所以它應(yīng)該是 500M。RES 為實際分配的物理內(nèi)存數(shù)量，我們看到這個值就在 300M 上下浮動?？礃幼游覀円呀?jīng)成功的限制了容器能夠使用的物理內(nèi)存數(shù)量。

限制可用的 swap 大小

強調(diào)一下 --memory-swap 是必須要與 --memory 一起使用的。

正常情況下， --memory-swap 的值包含容器可用內(nèi)存和可用 swap。所以 --memory="300m" --memory-swap="1g" 的含義為：

容器可以使用 300M 的物理內(nèi)存，并且可以使用 700M(1G -330M) 的 swap。--memory-swap 居然是容器可以使用的物理內(nèi)存和可以使用的 swap 之和！

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

如果 --memory-swap 的值和 --memory 相同，則容器不能使用 swap。下面的 demo 演示了在沒有 swap 可用的情況下向系統(tǒng)申請大量內(nèi)存的場景：

$ docker run -it --rm -m 300M --memory-swap=300M u-stress /bin/bash
# stress --vm 1 --vm-bytes 500M

demo 中容器的物理內(nèi)存被限制在 300M，但是進程卻希望申請到 500M 的物理內(nèi)存。在沒有 swap 可用的情況下，進程直接被 OOM kill 了。如果有足夠的 swap，程序至少還可以正常的運行。

我們可以通過 --oom-kill-disable 選項強行阻止 OOM kill 的發(fā)生，但是筆者認(rèn)為 OOM kill 是一種健康的行為，為什么要阻止它呢？

除了限制可用 swap 的大小，還可以設(shè)置容器使用 swap 的緊迫程度，這一點和主機的 swappiness 是一樣的。容器默認(rèn)會繼承主機的 swappiness，如果要顯式的為容器設(shè)置 swappiness 值，可以使用 --memory-swappiness 選項。

總結(jié)

通過限制容器可用的物理內(nèi)存，可以避免容器內(nèi)服務(wù)異常導(dǎo)致大量消耗主機內(nèi)存的情況(此時讓容器重啟是較好的策略)，因此可以降低主機內(nèi)存被耗盡帶來的風(fēng)險。

最新評論