原文地址：https://docs.docker.com/engine/admin/resource_constraints/#configure-the-realtime-scheduler

摘要

    在Docker中預設情況下容器的資源只受到host端核心資源排程的限制。但是可以在使用docker run命令啟動容器時新增一些資源控制標誌來控制容器的memroy,cpu以及block IO資源分配。

    本文將介紹這些控制標誌使用細節及其意義。

一、Memory記憶體

1.1 OOM的危害

    有時候我們有必要限制一個容器的記憶體用量以免它肆無忌憚的消耗host主機記憶體，導致系統記憶體緊張。在host端linux系統中，若記憶體資源消耗到極度緊缺的狀態時一些關鍵任務將無法再繼續正常執行，這將會引發Out of Memory Exception(OOME)。此時核心會選擇一個程序(一般是記憶體消耗極大的程序)來殺掉以釋放出記憶體。任何程序都有可能被殺到，包括Docker或者其他重要的應用程序；如果被殺到的是系統中重要的程序就很可能會影響系統穩定。

    Docker可以通過調整Docker daemon的OOM priority來儘量降低系統發生OOM時被kill掉的風險。預設情況下容器的的OOM priority是沒有被經過調整的，在發生OOME時核心就會傾向於"幹掉"某個容器，而非Docker daemon或者系統中重要的程序。如果有必要，我們也可以通過引數--oom-score-adj(後面帶一個很小的負值)或者--oom-disable-kill引數
來保護Docker daemon或者某個重要的容器在發生OOM時儘量不被核心給殺掉。

   更多linux 核心OOM管理的詳細資訊，參考

Out of Memory Management

    我們還可以通過如下途徑來減少OOME帶來的風險:
    (1) 在應用正式釋出前進行充分的效能測試，以對它的記憶體消耗量有所瞭解；
    (2) 確保我們的應用消耗合理的資源量；
    (3) 限制容器的記憶體使用量，下面會詳細介紹；
    (4) 要注意Docker host端配置了swap的情況。記憶體交換會影響效能和速度，但在系統記憶體緊張時會起到一定的緩衝作用。
    (5) 如果可以，將容器改造成服務程序，然後使用service-level限制或node labels來確保應用在主機上有足夠記憶體執行。

1.2 容器的記憶體限制

    容器的記憶體資源限制有hard limit或者soft limit限制。
    對於hard limit，容器記憶體不能超過設定的記憶體上限；對於soft limit，除非系統記憶體緊張或者記憶體資源爭奪激勵等等情況發生，否則一般在系統記憶體資源寬裕的情況下容器可以不受限制的自由申請記憶體。
    容器記憶體資源限制的選項標誌一旦設定，會對容器的執行產生影響。

    這些選項標誌的值格式為正整數加單位，如b(bytes), k(kilobytes), m(megabytes), g(gigabytes)。

選項	描述
-m,--memory	記憶體限制，格式是數字加單位，單位可以為 b,k,m,g。最小為 4M。
--memory-swap	可交換分割槽記憶體的大小，詳細見下面--memory-swap(一節)
--memory-swappiness	預設情況下host端核心可將容器使用的anonymous pages按一定的比例交換出去。可為此標誌設定一個 0~100 之間的整數值來調整這個比例。
--memory-reservation	記憶體資源軟限制，其值一般不超過--memory的值(實際可以設定超過--memory，但是那樣一來這個軟限制實質沒有起到作用)。軟限制一般會在系統記憶體緊張時才起作用，它不保證容器的記憶體使用不超過這個限制。
--kernel-memory	容器的核心記憶體限制，最小為 4M。由於核心記憶體無法交換出去，對核心記憶體大量需求的容器可能會造成host端資源的緊張，從而影響到host端或在其他容器參考"-"-kernel-memory 一節。
--oom-kill-disable	使用此標誌可阻止 OOM發生時被核心kill掉。要用此標誌保證容器不被OOM killer殺掉還需要設定-m/"-"-memroy選項;如果不設定-m選項，host端可能會有記憶體耗盡的風險，此時核心會殺掉系統中的程序以釋放記憶體。
--oom-score-adj	容器被 OOM killer 殺死的優先順序，範圍是[-1000, 1000]，預設為 0

    關於cgroups和memory更多的詳細資訊參考文件Memroy Resource Controller。

1.3 memory-swap

    --memory-swap標誌只有在 --memory也設定時才有意義。使用此標誌容器可以在耗盡它的可用記憶體資源後將超額的記憶體交換到磁碟上。當然，頻繁的記憶體交換會導致效能的損耗。
    這個標誌的設定會產生如下一些影響：
     (1) 如果--memory-swap設定為一個正整數，則 --memory標誌也必須設定。 --memory-swap代表"記憶體"+"交換分割槽"的總量;--memory表示非交換記憶體的總量。舉個例子：--memory="300M"  而  --memory-swap="1g"，則容器可用的記憶體為300M，而交換分割槽為700M;
    (2) 如果--memory-swap 設定為0,則忽略此標誌;
    (3) 如果 --memory-swap的值與 --memory相等 ( --memory設定為正值)，則其效果相當於 --memory-swap設定為0;
    (4) 如果沒有設定 --memory-swap標誌，但設定了 --memory，則容器可獲得2倍於 --memory的交換分割槽。例如，如果 --memory="300M"， 而 --memory-swap 沒有設定，實際上容器可使用300M記憶體+600M交換分割槽;
    (5) 如果 --memory-swap 設定為 -1，則容器的的交換分割槽不受Docker限制，只受到host系統可用資源限制。

1.4 --memory-swappiness

    (1) 0值表示關掉 anonymous 頁的交換;
    (2) 設定為100表示所有的匿名頁都可交換;
    (3) 如果沒有設定此標誌，其預設值與host的值保持一致。

1.5 --kernel-memory

    核心記憶體不同於使用者記憶體，它不能交換到磁碟，它包括： 
      *stack pages
      *slab pages
      *sockets memory pressure
      *tcp memory pressure
    --kernel-memory與 --memory有一定的聯絡，它是在 --memroy的上下文中限制核心記憶體，即核心記憶體的消耗會計入到 --memory的消耗中。
    請看如下場景：
      *Unlimited memory, unlimited kernel memory: 預設配置;
      *Unlimited memory, limited kernel memory：如果所有cgroup所需的記憶體總量超過host系統實際的記憶體總量時可選這種配置。這種情況下，可以限制核心記憶體數量不超過host主機可用記憶體。當容器需要更多記憶體時則需要等待。
      *Limited memory, umlimited kernel memory: 只對總的記憶體限制，但不單獨限制kernel記憶體。
      *Limited memory, limited kernel memory: 同時限制使用者記憶體和核心記憶體。這在進行記憶體相關的問題調式時有用。(1) 若核心記憶體限制低於使用者記憶體限制，當容器核心記憶體超限會引發一個OOM;(2)若核心記憶體限制高於使用者記憶體限制，則不會導致容器發生OOM。

     一旦開啟任一記憶體限制，host端將會監控程序的"high 水線"值;我們也可以據此追蹤哪個程序(這裡實際是容器)的記憶體超限，這可以在主機端通過/proc/<PID>/status來檢視。

二、CPU資源

     預設情況下沒有限制容器的cpu(時間)資源，我們可以手動為容器設定這種限制。一般情況下是設定CFS排程相關的cpu時間(大部分的任務都是普通任務，即使用的是CFS排程)。在Docker1.13或更高版本中，可以對實時排程任務的cpu時間進行配置。

2.1 CFS排程中cpu分配

     在linux中普通程序都使用CFS演算法來進行排程。可以通過相關的標誌來配置容器可用的cpu資源，容器 使用這些標誌，實際上是操作了容器在host端的cgroup相關的配置項。下表列出了一些標誌：

Options	Description
--cpus=<value>	表示分配給容器可用的cpu資源。例如：host系統有2個cpu，我們為容器指定了 --cpu="1.5" , 這樣就保證了容器最多可以使用"1.5"個cpus資源。這與 --cpu-period="1000000" 加上 --cpu-quota="1500000"的設定等價。此標誌在Docker 1.3或更高版本才支援。
--cpu-period=<value>	指定CFS排程的週期，一般與 --cpu-quota一起使用。預設情況下週期為1 秒，以微秒為單位表示，一般使用預設值。1.13或者更高版本推薦使用 --cpus 標誌代替。
--cpu-quota=<value>	在CFS排程中容器一個週期的cpu時間配額，即每個 --cpu-period週期容器可獲得的cpu時間(微秒)，cpu-quota/cpu-period。1.13或者更高版本推薦使用 --cpus 標誌代替。
--cpuset-cpus	指定容器執行在哪個cpu或cpu core上。其值可以是逗號“，”分隔的各個cpu號，也可以通過"-"指定一個cpu範圍。在多cpu系統中，cpu從0號開始編號。舉個例子：0-3表示容器可以使用cpu0,cpu1,cpu2,cpu3;而1,3則表示只能使用 cpu1和cpu3。
--cpu-shares	用以設定容器的權重，CFS排程中程序的預設權重是1024。在cpu資源有限的情下權重值才會起作用;如果cpu資源充足，各個容器都可獲得足夠的cpu執行時間，這個時候 --cpu-shares相當於一個軟限制。

    下面看一下系統只有1個cpu的情況下，下面的設定可以保證各個容器最多隻能分配50%的cpu時間。
     (1) Docker 1.13或者更高版本

docker run -it --cpus=".5" ubuntu /bin/bash

     (2)Docker 1.12或者更低版本

$ docker run -it --cpu-period=100000 --cpu-quota=50000 ubuntu /bin/bash

2.2 實時排程的配置

    在Docker1.13或者更高的版本中，可以為容器的實時排程進行配置。在配置docker daemon或者容器前，首先要保證host核心使能了相應的配置。

 HSOT端的核心配置

     我們通過 zcat /proc/config.gz | grep CONFIG_RT_GROUP_SCHED 來確認host核心是否使能CONFIG_RT_GROUP_SCHED配置項，也可以通過檢查/sys/fs/cgroup/cpu.rt_runtime_us檔案是否存在來進行確認。

DOCKER DAEMON的配置

    如果容器需要實時排程(有實 任務)，啟動Docker daemon時通過 --cpu-rt-runtime標誌來指定容器中實時任務在一個週期內可佔用的最大cpu時間(單位為微秒)。
    舉個例子，在統的預設週期1000000 us(1秒)的情況下，設定 --cpu-rt-runtime=950000可以保證保證容器中的實時任務在一個週期內最多可以獲得950毫秒的cpu時間，週期內剩餘的50ms可分配給非實時任務。
   在具有systemd的系統上如果要讓這些配置永久生效，可以參看Control and configure Docker with systemd(https://docs.docker.com/engine/admin/systemd/)。

單個容器的配置

    在用docker run啟動容器時，可以通過一些標誌來控制容器的CPU資源分配。

Option	Description
-cap-add=sys_nice	容器具有CAP_SYS_NICE許可權,這可以允許容器修改自己的nice值,設定為實時排程策略,設定cpu親和性等等操作
--cpu-rt-runtime=<value>	一個實時週期內可執行的最大cpu時間，需要設定--cap-add=sys_nice標誌
--ulimit rtprio=<value>	容器的最高實時優先順序，需要設定--cap-add=sys_nice標誌

    看看下面這個例子：

$ docker run --it --cpu-rt-runtime=95000 \
                  --ulimit rtprio=99 \
                  --cap-add=sys_nice \
                  debian:jessie

    上例表示從debian:jessie執行一個擁有CAP_SYS_NICE特權，且實時優先順序為99，週期內最大實時cpu時間為950ms的容器。