Docker(二十)-Docker容器CPU、memory資源限制

背景

在使用 docker 運作容器時，預設的情況下，docker沒有對容器進行硬體資源的限制，當一台主機上運作幾百個容器，這些容器雖然互相隔離，但是底層卻使用着相同的 CPU、記憶體和磁盤資源。如果不對容器使用的資源進行限制，那麼容器之間會互相影響，小的來說會導緻容器資源使用不公平；大的來說，可能會導緻主機和叢集資源耗盡，服務完全不可用。

docker 作為容器的管理者，自然提供了控制容器資源的功能。正如使用核心的 namespace 來做容器之間的隔離，docker 也是通過核心的 cgroups 來做容器的資源限制；包括CPU、記憶體、磁盤三大方面，基本覆寫了常見的資源配額和使用量控制。

Docker記憶體控制OOME在linxu系統上，如果核心探測到目前主控端已經沒有可用記憶體使用，那麼會抛出一個OOME(Out Of Memory Exception:記憶體異常 )，并且會開啟killing去殺掉一些程序。

一旦發生OOME，任何程序都有可能被殺死，包括docker daemon在内，為此，docker特地調整了docker daemon的OOM_Odj優先級，以免他被殺掉，但容器的優先級并未被調整。經過系統内部複制的計算後，每個系統程序都會有一個OOM_Score得分，OOM_Odj越高，得分越高，（在docker run的時候可以調整OOM_Odj）得分最高的優先被kill掉，當然，也可以指定一些特定的重要的容器禁止被OMM殺掉，在啟動容器時使用 –oom-kill-disable=true指定。

參考：Docker監控容器資源的占用情況

cgroup簡介

cgroup是Control Groups的縮寫，是Linux 核心提供的一種可以限制、記錄、隔離程序組所使用的實體資源(如 cpu、memory、磁盤IO等等) 的機制，被LXC、docker等很多項目用于實作程序資源控制。cgroup将任意程序進行分組化管理的 Linux 核心功能。cgroup本身是提供将程序進行分組化管理的功能和接口的基礎結構，I/O 或記憶體的配置設定控制等具體的資源管理功能是通過這個功能來實作的。這些具體的資源管理功能稱為cgroup子系統，有以下幾大子系統實作：

1. blkio：設定限制每個塊裝置的輸入輸出控制。例如:磁盤，CD光牒以及usb等等。
2. cpu：使用排程程式為cgroup任務提供cpu的通路。
3. cpuacct：産生cgroup任務的cpu資源報告。
4. cpuset：如果是多核心的cpu，這個子系統會為cgroup任務配置設定單獨的cpu和記憶體。
5. devices：允許或拒絕cgroup任務對裝置的通路。
6. freezer：暫停和恢複cgroup任務。
7. memory：設定每個cgroup的記憶體限制以及産生記憶體資源報告。
8. net_cls：标記每個網絡包以供cgroup友善使用。
9. ns：命名空間子系統。
10. perf_event：增加了對每group的監測跟蹤的能力，即可以監測屬于某個特定的group的所有線程以及運作在特定CPU上的線程。

目前docker隻是用了其中一部分子系統，實作對資源配額和使用的控制。

可以使用stress工具來測試CPU和記憶體。使用下面的Dockerfile來建立一個基于Ubuntu的stress工具鏡像。

FROM ubuntu:14.04

RUN apt-get update &&apt-get install stress

資源監控的關鍵目錄：cat讀出

已使用記憶體：

/sys/fs/cgroup/memory/docker/應用ID/memory.usage_in_bytes

配置設定的總記憶體：

/sys/fs/cgroup/memory/docker/應用ID/memory.limit_in_bytes

已使用的cpu：機關納秒

/sys/fs/cgroup/cpuacct/docker/應用ID/cpuacct.usage

系統目前cpu：

$ cat /proc/stat | grep 'cpu '（周期/時間片/jiffies）
#得到的數字相加/HZ（cat /boot/config-`uname -r` | grep '^CONFIG_HZ='
ubuntu 14.04為250）就是系統時間（秒）
#再乘以10*9就是系統時間（納秒）           

例子

[~]$ cat /proc/stat
cpu 432661 13295 86656 422145968 171474 233 5346
cpu0 123075 2462 23494 105543694 16586 0 4615
cpu1 111917 4124 23858 105503820 69697 123 371
cpu2 103164 3554 21530 105521167 64032 106 334
cpu3 94504 3153 17772 105577285 21158 4 24
intr 1065711094 1057275779 92 0 6 6 0 4 0 3527 0 0 0 70 0 20 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
ctxt 19067887
btime 1139187531
processes 270014
procs_running 1
procs_blocked 0


輸出解釋
CPU 以及CPU0、CPU1、CPU2、CPU3每行的每個參數意思（以第一行為例）為：
參數 解釋
user (432661) 從系統啟動開始累計到目前時刻，使用者态的CPU時間（機關：jiffies） ，不包含 nice值為負程序。
nice (13295) 從系統啟動開始累計到目前時刻，nice值為負的程序所占用的CPU時間（機關：jiffies） 
system (86656) 從系統啟動開始累計到目前時刻，核心時間（機關：jiffies） 
idle (422145968) 從系統啟動開始累計到目前時刻，除硬碟IO等待時間以外其它等待時間（機關：jiffies） 
iowait (171474) 從系統啟動開始累計到目前時刻，硬碟IO等待時間（機關：jiffies） ，
irq (233) 從系統啟動開始累計到目前時刻，硬中斷時間（機關：jiffies） 
softirq (5346) 從系統啟動開始累計到目前時刻，軟中斷時間（機關：jiffies）            

cpu使用率：

（已使用2-已使用1）/（系統目前2-系統目前1）*100%

記憶體限制

Docker 提供的記憶體限制功能有以下幾點：

• 容器能使用的記憶體和交換分區大小。
• 容器的核心記憶體大小。
• 容器虛拟記憶體的交換行為。
• 容器記憶體的軟性限制。
• 是否殺死占用過多記憶體的容器。
• 容器被殺死的優先級

一般情況下，達到記憶體限制的容器過段時間後就會被系統殺死。

記憶體限制相關的參數

執行

docker run

指令時能使用的和記憶體限制相關的所有選項如下。

選項	描述
-m , --memory	記憶體限制，格式是數字加機關，機關可以為 b,k,m,g。最小為 4M
--memory-swap	記憶體+交換分區大小總限制。格式同上。必須必 -m 設定的大
--memory-reservation	記憶體的軟性限制。格式同上
--oom-kill-disable	是否阻止 OOM killer 殺死容器，預設沒設定
--oom-score-adj	容器被 OOM killer 殺死的優先級，範圍是[-1000, 1000]，預設為 0
--memory-swappiness	用于設定容器的虛拟記憶體控制行為。值為 0~100 之間的整數
--kernel-memory	核心記憶體限制。格式同上，最小為 4M

使用者記憶體限制

使用者記憶體限制就是對容器能使用的記憶體和交換分區的大小作出限制。使用時要遵循兩條直覺的規則：

-m，--memory

選項的參數最小為 4 M。

--memory-swap

不是交換分區，而是記憶體加交換分區的總大小，是以

--memory-swap

必須比

-m,--memory

大。在這兩條規則下，一般有四種設定方式。

你可能在進行記憶體限制的實驗時發現

docker run

指令報錯：WARNING: Your kernel does not support swap limit capabilities, memory limited without swap.

這是因為主控端核心的相關功能沒有打開。按照下面的設定就行。

step 1：編輯

/etc/default/grub

檔案，将

GRUB_CMDLINE_LINUX

一行改為

GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"

step 2：更新 GRUB，即執行

$ sudo update-grub

step 3: 重新開機系統。

1. 不設定

如果不設定

-m,--memory

和

--memory-swap

，容器預設可以用完宿舍機的所有記憶體和 swap 分區。不過注意，如果容器占用主控端的所有記憶體和 swap 分區超過一段時間後，會被主控端系統殺死（如果沒有設定

--00m-kill-disable=true

的話）。

2. 設定

-m,--memory

，不設定

--memory-swap

給

-m

或

--memory

設定一個不小于 4M 的值，假設為 a，不設定

--memory-swap

，或将

--memory-swap

設定為 0。這種情況下，容器能使用的記憶體大小為 a，能使用的交換分區大小也為 a。因為 Docker 預設容器交換分區的大小和記憶體相同。

如果在容器中運作一個一直不停申請記憶體的程式，你會觀察到該程式最終能占用的記憶體大小為 2a。

比如

$ docker run -m 1G ubuntu:16.04

，該容器能使用的記憶體大小為 1G，能使用的 swap 分區大小也為 1G。容器内的程序能申請到的總記憶體大小為 2G。

3. 設定

-m,--memory=a

，

--memory-swap=b

，且b > a

-m

設定一個參數 a，給

--memory-swap

設定一個參數 b。a 時容器能使用的記憶體大小，b是容器能使用的 記憶體大小 + swap 分區大小。是以 b 必須大于 a。b -a 即為容器能使用的 swap 分區大小。

$ docker run -m 1G --memory-swap 3G ubuntu:16.04

，該容器能使用的記憶體大小為 1G，能使用的 swap 分區大小為 2G。容器内的程序能申請到的總記憶體大小為 3G。

4. 設定

-m,--memory=a

--memory-swap=-1

-m

參數設定一個正常值，而給

--memory-swap

設定成 -1。這種情況表示限制容器能使用的記憶體大小為 a，而不限制容器能使用的 swap 分區大小。

這時候，容器内程序能申請到的記憶體大小為 a + 主控端的 swap 大小。

Memory reservation

這種 memory reservation 機制不知道怎麼翻譯比較形象。Memory reservation 是一種軟性限制，用于節制容器記憶體使用。給

--memory-reservation

設定一個比

-m

小的值後，雖然容器最多可以使用

-m

使用的記憶體大小，但在主控端記憶體資源緊張時，在系統的下次記憶體回收時，系統會回收容器的部分記憶體頁，強迫容器的記憶體占用回到

--memory-reservation

設定的值大小。

沒有設定時（預設情況下）

--memory-reservation

的值和

-m

的限定的值相同。将它設定為 0 會設定的比

-m

的參數大 等同于沒有設定。

Memory reservation 是一種軟性機制，它不保證任何時刻容器使用的記憶體不會超過

--memory-reservation

限定的值，它隻是確定容器不會長時間占用超過

--memory-reservation

限制的記憶體大小。

例如：

$ docker run -it -m 500M --memory-reservation 200M ubuntu:16.04 /bin/bash           

如果容器使用了大于 200M 但小于 500M 記憶體時，下次系統的記憶體回收會嘗試将容器的記憶體鎖緊到 200M 以下。

$ docker run -it --memory-reservation 1G ubuntu:16.04 /bin/bash           

容器可以使用盡可能多的記憶體。

--memory-reservation

確定容器不會長時間占用太多記憶體。

OOM killer

預設情況下，在出現 out-of-memory(OOM) 錯誤時，系統會殺死容器内的程序來擷取更多空閑記憶體。這個殺死程序來節省記憶體的程序，我們姑且叫它 OOM killer。我們可以通過設定

--oom-kill-disable

選項來禁止 OOM killer 殺死容器内程序。但請確定隻有在使用了

-m/--memory

選項時才使用

--oom-kill-disable

禁用 OOM killer。如果沒有設定

-m

選項，卻禁用了 OOM-killer，可能會造成出現 out-of-memory 錯誤時，系統通過殺死主控端程序或擷取更改記憶體。

下面的例子限制了容器的記憶體為 100M 并禁止了 OOM killer：

$ docker run -it -m 100M --oom-kill-disable ubuntu:16.04 /bin/bash           

是正确的使用方法。

而下面這個容器沒設定記憶體限制，卻禁用了 OOM killer 是非常危險的：

$ docker run -it --oom-kill-disable ubuntu:16.04 /bin/bash           

容器沒用記憶體限制，可能或導緻系統無記憶體可用，并嘗試時殺死系統程序來擷取更多可用記憶體。

一般一個容器隻有一個程序，這個唯一程序被殺死，容器也就被殺死了。我們可以通過

--oom-score-adj

選項來設定在系統記憶體不夠時，容器被殺死的優先級。負值更教不可能被殺死，而正值更有可能被殺死。

核心記憶體

核心記憶體和使用者記憶體不同的地方在于核心記憶體不能被交換出。不能交換出去的特性使得容器可以通過消耗太多記憶體來堵塞一些系統服務。核心記憶體包括：

• stack pages（棧頁面）
• slab pages
• socket memory pressure
• tcp memory pressure

可以通過設定核心記憶體限制來限制這些記憶體。例如，每個程序都要消耗一些棧頁面，通過限制核心記憶體，可以在核心記憶體使用過多時阻止新程序被建立。

核心記憶體和使用者記憶體并不是獨立的，必須在使用者記憶體限制的上下文中限制核心記憶體。

假設使用者記憶體的限制值為 U，核心記憶體的限制值為 K。有三種可能地限制核心記憶體的方式：

1. U != 0，不限制核心記憶體。這是預設的标準設定方式
2. K < U，核心記憶體時使用者記憶體的子集。這種設定在部署時，每個 cgroup 的記憶體總量被過度使用。過度使用核心記憶體限制是絕不推薦的，因為系統還是會用完不能回收的記憶體。在這種情況下，你可以設定 K，這樣 groups 的總數就不會超過總記憶體了。然後，根據系統服務的品質自有地設定 U。
3. K > U，因為核心記憶體的變化也會導緻使用者計數器的變化，容器核心記憶體和使用者記憶體都會觸發回收行為。這種配置可以讓管理者以一種統一的視圖看待記憶體。對想跟蹤核心記憶體使用情況的使用者也是有用的。

$ docker run -it -m 500M --kernel-memory 50M ubuntu:16.04 /bin/bash           

容器中的程序最多能使用 500M 記憶體，在這 500M 中，最多隻有 50M 核心記憶體。

$ docker run -it --kernel-memory 50M ubuntu:16.04 /bin/bash           

沒用設定使用者記憶體限制，是以容器中的程序可以使用盡可能多的記憶體，但是最多能使用 50M 核心記憶體。

Swappiness

預設情況下，容器的核心可以交換出一定比例的匿名頁。

--memory-swappiness

就是用來設定這個比例的。

--memory-swappiness

可以設定為從 0 到 100。0 表示關閉匿名頁面交換。100 表示所有的匿名頁都可以交換。預設情況下，如果不适用

--memory-swappiness

，則該值從父程序繼承而來。

$ docker run -it --memory-swappiness=0 ubuntu:16.04 /bin/bash

           

将

--memory-swappiness

設定為 0 可以保持容器的工作集，避免交換代理的性能損失。

$ docker run -tid —name mem1 —memory 128m ubuntu:16.04 /bin/bash
$ cat /sys/fs/cgroup/memory/docker/<容器的完整ID>/memory.limit_in_bytes
$ cat /sys/fs/cgroup/memory/docker/<容器的完整ID>/memory.memsw.limit_in_bytes           

CPU 限制

概述

Docker 的資源限制和隔離完全基于 Linux cgroups。對 CPU 資源的限制方式也和 cgroups 相同。Docker 提供的 CPU 資源限制選項可以在多核系統上限制容器能利用哪些 vCPU。而對容器最多能使用的 CPU 時間有兩種限制方式：一是有多個 CPU 密集型的容器競争 CPU 時，設定各個容器能使用的 CPU 時間相對比例。二是以絕對的方式設定容器在每個排程周期内最多能使用的 CPU 時間。

CPU 限制相關參數

docker run

指令和 CPU 限制相關的所有選項如下：

--cpuset-cpus=""	允許使用的 CPU 集，值可以為 0-3,0,1
-c --cpu-shares=0	CPU 共享權值（相對權重）
cpu-period=0	限制 CPU CFS 的周期，範圍從 100ms~1s，即[1000, 1000000]
--cpu-quota=0	限制 CPU CFS 配額，必須不小于1ms，即 >= 1000
--cpuset-mems=""	允許在上執行的記憶體節點（MEMs），隻對 NUMA 系統有效

其中

--cpuset-cpus

用于設定容器可以使用的 vCPU 核。

-c

--cpu-shares

用于設定多個容器競争 CPU 時，各個容器相對能配置設定到的 CPU 時間比例。

--cpu-period

--cpu-quata

用于絕對設定容器能使用 CPU 時間。

--cpuset-mems

暫用不上，這裡不談。

CPU 集

我們可以設定容器可以在哪些 CPU 核上運作。

$ docker run -it --cpuset-cpus="1,3" ubuntu:14.04 /bin/bash           

表示容器中的程序可以在 cpu 1 和 cpu 3 上執行。

$ docker run -it --cpuset-cpus="0-2" ubuntu:14.04 /bin/bash
$ cat /sys/fs/cgroup/cpuset/docker/<容器的完整長ID>/cpuset.cpus
           

表示容器中的程序可以在 cpu 0、cpu 1 及 cpu 3 上執行。

在 NUMA 系統上，我們可以設定容器可以使用的記憶體節點。

$ docker run -it --cpuset-mems="1,3" ubuntu:14.04 /bin/bash           

表示容器中的程序隻能使用記憶體節點 1 和 3 上的記憶體。

$ docker run -it --cpuset-mems="0-2" ubuntu:14.04 /bin/bash           

表示容器中的程序隻能使用記憶體節點 0、1、2 上的記憶體。

CPU 資源的相對限制

預設情況下，所有的容器得到同等比例的 CPU 周期。在有多個容器競争 CPU 時我們可以設定每個容器能使用的 CPU 時間比例。這個比例叫作共享權值，通過

-c

--cpu-shares

設定。Docker 預設每個容器的權值為 1024。不設定或将其設定為 0，都将使用這個預設值。系統會根據每個容器的共享權值和所有容器共享權值和比例來給容器配置設定 CPU 時間。

假設有三個正在運作的容器，這三個容器中的任務都是 CPU 密集型的。第一個容器的 cpu 共享權值是 1024，其它兩個容器的 cpu 共享權值是 512。第一個容器将得到 50% 的 CPU 時間，而其它兩個容器就隻能各得到 25% 的 CPU 時間了。如果再添加第四個 cpu 共享值為 1024 的容器，每個容器得到的 CPU 時間将重新計算。第一個容器的CPU 時間變為 33%，其它容器分得的 CPU 時間分别為 16.5%、16.5%、33%。

必須注意的是，這個比例隻有在 CPU 密集型的任務執行時才有用。在四核的系統上，假設有四個單程序的容器，它們都能各自使用一個核的 100% CPU 時間，不管它們的 cpu 共享權值是多少。

在多核系統上，CPU 時間權值是在所有 CPU 核上計算的。即使某個容器的 CPU 時間限制少于 100%，它也能使用各個 CPU 核的 100% 時間。

例如，假設有一個不止三核的系統。用

-c=512

的選項啟動容器

{C0}

，并且該容器隻有一個程序，用

-c=1024

的啟動選項為啟動容器

C2

，并且該容器有兩個程序。CPU 權值的分布可能是這樣的：

PID    container    CPU CPU share
100    {C0}     0   100% of CPU0
101    {C1}     1   100% of CPU1
102    {C1}     2   100% of CPU2

$ docker run -it --cpu-shares=100 ubuntu:14.04 /bin/bash
$ cat /sys/fs/cgroup/cpu/docker/<容器的完整長ID>/cpu.shares
           

表示容器中的程序CPU份額值為100。

CPU 資源的絕對限制

Linux 通過 CFS（Completely Fair Scheduler，完全公平排程器）來排程各個程序對 CPU 的使用。CFS 預設的排程周期是 100ms。

關于 CFS 的更多資訊，參考CFS documentation on bandwidth limiting。

我們可以設定每個容器程序的排程周期，以及在這個周期内各個容器最多能使用多少 CPU 時間。使用

--cpu-period

即可設定排程周期，使用

--cpu-quota

即可設定在每個周期内容器能使用的 CPU 時間。兩者一般配合使用。

$ docker run -it --cpu-period=50000 --cpu-quota=25000 ubuntu:16.04 /bin/bash           

将 CFS 排程的周期設為 50000，将容器在每個周期内的 CPU 配額設定為 25000，表示該容器每 50ms 可以得到 50% 的 CPU 運作時間。

$ docker run -it --cpu-period=10000 --cpu-quota=20000 ubuntu:16.04 /bin/bash
$ cat /sys/fs/cgroup/cpu/docker/<容器的完整長ID>/cpu.cfs_period_us
$ cat /sys/fs/cgroup/cpu/docker/<容器的完整長ID>/cpu.cfs_quota_us
           

将容器的 CPU 配額設定為 CFS 周期的兩倍，CPU 使用時間怎麼會比周期大呢？其實很好解釋，給容器配置設定兩個 vCPU 就可以了。該配置表示容器可以在每個周期内使用兩個 vCPU 的 100% 時間。

CFS 周期的有效範圍是 1ms~1s，對應的

--cpu-period

的數值範圍是 1000~1000000。而容器的 CPU 配額必須不小于 1ms，即

--cpu-quota

的值必須 >= 1000。可以看出這兩個選項的機關都是 us。

正确的了解“絕對”

注意前面我們用

--cpu-quota

設定容器在一個排程周期内能使用的 CPU 時間時實際上設定的是一個上限。并不是說容器一定會使用這麼長的 CPU 時間。比如，我們先啟動一個容器，将其綁定到 cpu 1 上執行。給其

--cpu-quota

--cpu-period

都設定為 50000。

$ docker run --rm --name test01 --cpu-cpus 1 --cpu-quota=50000 --cpu-period=50000 deadloop:busybox-1.25.1-glibc           

排程周期為 50000，容器在每個周期内最多能使用 50000 cpu 時間。

再用

docker stats test01

可以觀察到該容器對 CPU 的使用率在100%左右。然後，我們再以同樣的參數啟動另一個容器。

$ docker run --rm --name test02 --cpu-cpus 1 --cpu-quota=50000 --cpu-period=50000 deadloop:busybox-1.25.1-glibc           

docker stats test01 test02

可以觀察到這兩個容器，每個容器對 cpu 的使用率在 50% 左右。說明容器并沒有在每個周期内使用 50000 的 cpu 時間。

使用

docker stop test02

指令結束第二個容器，再加一個參數

-c 2048

啟動它：

$ docker run --rm --name test02 --cpu-cpus 1 --cpu-quota=50000 --cpu-period=50000 -c 2048 deadloop:busybox-1.25.1-glibc           

docker stats test01

指令可以觀察到第一個容器的 CPU 使用率在 33% 左右，第二個容器的 CPU 使用率在 66% 左右。因為第二個容器的共享值是 2048，第一個容器的預設共享值是 1024，是以第二個容器在每個周期内能使用的 CPU 時間是第一個容器的兩倍。

磁盤IO配額控制

相對于CPU和記憶體的配額控制，docker對磁盤IO的控制相對不成熟，大多數都必須在有主控端裝置的情況下使用。主要包括以下參數：

• –device-read-bps：限制此裝置上的讀速度（bytes per second），機關可以是kb、mb或者gb。
• –device-read-iops：通過每秒讀IO次數來限制指定裝置的讀速度。
• –device-write-bps ：限制此裝置上的寫速度（bytes per second），機關可以是kb、mb或者gb。
• –device-write-iops：通過每秒寫IO次數來限制指定裝置的寫速度。
• –blkio-weight：容器預設磁盤IO的權重值，有效值範圍為10-100。
• –blkio-weight-device： 針對特定裝置的IO權重控制。其格式為DEVICE_NAME:WEIGHT

存儲配額控制的相關參數，可以參考Red Hat文檔中blkio這一章，了解它們的詳細作用。

磁盤IO配額控制示例

blkio-weight

要使–blkio-weight生效，需要保證IO的排程算法為CFQ。可以使用下面的方式檢視：

root@ubuntu:~# cat /sys/block/sda/queue/scheduler

noop [deadline] cfq

使用下面的指令建立兩個–blkio-weight值不同的容器：

docker run -ti –rm –blkio-weight 100 ubuntu:stress

docker run -ti –rm –blkio-weight 1000 ubuntu:stress

在容器中同時執行下面的dd指令，進行測試：

time dd if=/dev/zero of=test.out bs=1M count=1024 oflag=direct

最終輸出如下圖所示：

在我的測試環境上沒有達到理想的測試效果，通過docker官方的blkio-weight doesn’t take effect in docker Docker

version 1.8.1 #16173，可以發現這個問題在一些環境上存在，但docker官方也沒有給出解決辦法。

device-write-bps

使用下面的指令建立容器，并執行指令驗證寫速度的限制。

docker run -tid –name disk1 –device-write-bps /dev/sda:1mb ubuntu:stress

通過dd來驗證寫速度，輸出如下圖示：

可以看到容器的寫磁盤速度被成功地限制到了1MB/s。device-read-bps等其他磁盤IO限制參數可以使用類似的方式進行驗證。

容器空間大小限制

在docker使用devicemapper作為存儲驅動時，預設每個容器和鏡像的最大大小為10G。如果需要調整，可以在daemon啟動參數中，使用dm.basesize來指定，但需要注意的是，修改這個值，不僅僅需要重新開機docker daemon服務，還會導緻主控端上的所有本地鏡像和容器都被清理掉。

使用aufs或者overlay等其他存儲驅動時，沒有這個限制。