摘要：標(biāo)簽空格分隔資源管理內(nèi)存磁盤注該文作者是，原文是。如果你運(yùn)行命令，你自己可以看到這個(gè)結(jié)構(gòu)當(dāng)我們想管理資源的時(shí)候，這個(gè)方法提供了很大的靈活性，因?yàn)槲覀兛梢苑謩e的管理每個(gè)組。

標(biāo)簽（空格分隔）： Docker 資源管理 內(nèi)存 CPU 磁盤 I/O

  
注：該文作者是 Marek Goldmann，原文是 Resource management in Docker。

在這篇博客文章中，我想談?wù)?Docker 容器資源管理的話題，我們往往不清楚它是怎樣工作的以及我們能做什么不能做什么。我希望你讀完這篇關(guān)于資源管理的博客文章之后，可以幫助你更容易理解這些。

  
注意：我們假設(shè)你在一個(gè) systemd 可用的系統(tǒng)上運(yùn)行了 Docker。如果你是使用 RHEL/CentOS 7+ 或 Fedora 19+，systemd 肯定可用，但是請(qǐng)注意在不同的 systemd 版本之間可能配置選項(xiàng)會(huì)有改變。有疑問時(shí)，使用你所工作的系統(tǒng)的 systemd 的 man pages。

目錄預(yù)覽

Docker 使用 cgroups 歸類運(yùn)行在容器中的進(jìn)程。這使你可以管理一組進(jìn)程的資源，可想而知，這是非常寶貴的。

如果你運(yùn)行一個(gè)操作系統(tǒng)，其使用 systemd 管理服務(wù)。每個(gè)進(jìn)程（不僅僅是容器中的進(jìn)程）都將被放入一個(gè) cgroups 樹中。如果你運(yùn)行 systemd-cgls 命令，你自己可以看到這個(gè)結(jié)構(gòu)：

$ systemd-cgls
├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 22
├─machine.slice
│ └─machine-qemux2drhel7.scope
│   └─29898 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name rhel7 -S -machine pc-i440fx-1.6,accel=kvm,usb=off -cpu SandyBridge -m 2048
├─system.slice
│ ├─avahi-daemon.service
│ │ ├─ 905 avahi-daemon: running [mistress.local
│ │ └─1055 avahi-daemon: chroot helpe
│ ├─dbus.service
│ │ └─890 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
│ ├─firewalld.service
│ │ └─887 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid
│ ├─lvm2-lvmetad.service
│ │ └─512 /usr/sbin/lvmetad -f
│ ├─abrtd.service
│ │ └─909 /usr/sbin/abrtd -d -s
│ ├─wpa_supplicant.service
│ │ └─1289 /usr/sbin/wpa_supplicant -u -f /var/log/wpa_supplicant.log -c /etc/wpa_supplicant/wpa_supplicant.conf -u -f /var/log/wpa_supplica
│ ├─systemd-machined.service
│ │ └─29899 /usr/lib/systemd/systemd-machined

[SNIP]

當(dāng)我們想管理資源的時(shí)候，這個(gè)方法提供了很大的靈活性，因?yàn)槲覀兛梢苑謩e的管理每個(gè)組。盡管這篇博客文章著重與容器，同樣的原則也適用于其他的進(jìn)程。

  
注意：如果你想知道更多關(guān)于 systemd 的知識(shí)，我強(qiáng)烈推薦 RHEL 7 的 Resource Management and Linux Containers Guide 。

在我的例子中，我將使用 stress 工具來幫助我生成容器的一些負(fù)載，因此我可以實(shí)際看到資源的申請(qǐng)限制。我使用這個(gè) Dockerfile 創(chuàng)建了一個(gè)名為 stress 的定制的 Docker 鏡像：

FROM fedora:latest
RUN yum -y install stress && yum clean all
ENTRYPOINT ["stress"]

你使用這個(gè)工具來報(bào)告如 top， /proc/meminfo 等等 cgroups 不知道的使用情況。這意味著你將報(bào)告關(guān)于這臺(tái)主機(jī)的信息，盡管我們?cè)谌萜髦羞\(yùn)行著它們。我發(fā)現(xiàn)了一篇很好來自于 Fabio Kung 的關(guān)于這個(gè)主題的文章。讀一讀它吧。

因此，我們能做什么？

如果你想快速發(fā)現(xiàn)在該主機(jī)上哪個(gè)容器（或是最近的任何 systemd 服務(wù)）使用最多資源，我推薦 systemd-cgtop 命令：

$ systemd-cgtop
Path                                    Tasks   %CPU   Memory  Input/s Output/s

/                                         226   13.0     6.7G        -        -
/system.slice                              47    2.2    16.0M        -        -
/system.slice/gdm.service                   2    2.1        -        -        -
/system.slice/rngd.service                  1    0.0        -        -        -
/system.slice/NetworkManager.service        2      -        -        -        -

[SNIP]

這個(gè)工具能立刻給你一個(gè)快速預(yù)覽什么運(yùn)行在系統(tǒng)上。但是如果你想得到關(guān)系使用情況的更詳細(xì)信息（比如，你需要?jiǎng)?chuàng)建一個(gè)好看的圖表），你將去分析 /sys/fs/cgroup/…? 目錄。我將向你展示去哪里能找到我們將討論的每個(gè)資源的有用文件（看下面的 CGroups fs 段落）。

Docker 能夠指定（通過運(yùn)行命令的 -c 開關(guān)）給一個(gè)容器的可用的 CPU 分配值。這是一個(gè)相對(duì)權(quán)重，與實(shí)際的處理速度無關(guān)。事實(shí)上，沒有辦法說一個(gè)容器應(yīng)該只獲得 1Ghz CPU。記住。

默認(rèn)，每個(gè)新的容器將有 1024 shares 的 CPU，當(dāng)我們多帶帶講它的時(shí)候，這個(gè)值并不意味著什么。但是如果我們啟動(dòng)兩個(gè)容器并且兩個(gè)都將使用 100% CPU，CPU 時(shí)間將在這兩個(gè)容器之間平均分割，因?yàn)樗鼈儍蓚€(gè)都有同樣的 CPU shares（為了簡(jiǎn)單起見，我假設(shè)它們沒有任何進(jìn)程在運(yùn)行）。

如果我們?cè)O(shè)置容器的 CPU shares 是 512，相對(duì)于另外一個(gè)容器，它將使用一半的 CPU 時(shí)間。但這不意味著它僅僅能使用一半的 CPU 時(shí)間。如果另外一個(gè)容器（1024 shares 的）是空閑的 - 我們的容器將被允許使用 100% CPU。這是需要注意的另外一件事。

限制是僅僅當(dāng)它們應(yīng)該被執(zhí)行的時(shí)候才會(huì)強(qiáng)制執(zhí)行。CGroups 不限制進(jìn)程預(yù)先使用（比如，不允許它們?cè)试S的更快，即使它們有空余資源）。相反它提供了它盡可能提供的，以及它僅僅在必需的時(shí)候限制（比如，當(dāng)太多的進(jìn)程同時(shí)大量使用 CPU）。

當(dāng)然，這很難說清楚（我想說的是這不可能說清楚的）多少資源應(yīng)該被分配給你的進(jìn)程。這實(shí)際取決于其他進(jìn)程的行為和多少 shares 被分配給它們。

正如我在前面提到的，你可以使用 -c 開關(guān)來分配給運(yùn)行在容器中的所有進(jìn)程的 shares 值。

因?yàn)樵谖业臋C(jī)器上我有 4 核，我將使用 4 壓測(cè)：

$ docker run -it --rm stress --cpu 4
stress: info: [1] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd

如果你想以相同的方式啟動(dòng)兩個(gè)容器，兩個(gè)都將使用 50% 左右的 CPU。但是當(dāng)我們修改其中一個(gè)容器的 shares 時(shí)，將發(fā)生什么？

$ docker run -it --rm -c 512 stress --cpu 4
stress: info: [1] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd

正如你所看到的，CPU 在兩個(gè)容器之間是以這樣的方式分割了，第一個(gè)容器使用了 60% 的 CPU，另外一個(gè)使用了 30% 左右。這似乎是預(yù)期的結(jié)果。

  
注：丟失的 10% CPU 被 GNOME，Chrome 和我的音樂播放器使用了。

除了限制 CPU 的 shares（股份，相當(dāng)于配額的意思），我們可以做更多的事情，我們可以把容器的進(jìn)程固定到特定的處理器（core）。為了做到這個(gè)，我們使用 docker run 命令的 --cpuset 開關(guān)。

為了允許僅在第一個(gè)核上執(zhí)行：

docker run -it --rm --cpuset=0 stress --cpu 1

為了允許僅在第一個(gè)和第二個(gè)核上執(zhí)行：

docker run -it --rm --cpuset=0,1 stress --cpu 2

你當(dāng)然可以混合使用選項(xiàng) --cpuset 和 -c。

  
注意：Share enforcement 僅僅發(fā)生在當(dāng)進(jìn)程運(yùn)行在相同的核上的時(shí)候。這意味著如果你把一個(gè)容器固定在第一個(gè)核，而把另外一個(gè)容器固定在另外一個(gè)核，兩個(gè)都將使用各自核的 100%，即使它們有不同的 CPU shares 設(shè)置（再一次，我假設(shè)僅僅有兩個(gè)容器運(yùn)行在主機(jī)上）。

有可能改變一個(gè)正在運(yùn)行的容器的 shares（或是任何進(jìn)程）。你可以直接與 cgroups 文件系統(tǒng)交互，但是因?yàn)槲覀冇?systemds，我們可以通過它來為我們管理。

為了這個(gè)目的，我們將使用 systemctl 命令和 set-property 參數(shù)。使用 docker run 命令新的容器將有一個(gè) systemd scope，自動(dòng)分配到其內(nèi)的所有進(jìn)程都將被執(zhí)行。為了改變?nèi)萜髦兴羞M(jìn)程的 CPU share，我們僅僅需要在 scope 內(nèi)改變它，像這樣：

$ sudo systemctl set-property docker-4be96b853089bc6044b29cb873cac460b429cfcbdd0e877c0868eb2a901dbf80.scope CPUShares=512

  
注意：添加 --runtime 暫時(shí)的改變?cè)O(shè)置。否則，當(dāng)主機(jī)重起的時(shí)候，這個(gè)設(shè)置會(huì)被記住。

把默認(rèn)值從 1024 變更到 512。你可以在下面看到結(jié)果。這一變化發(fā)生在記錄的中間。請(qǐng)注意 CPU 使用率。在 systemd-cgtop 中 100% 意味著滿額使用了一核，并且這是正確的，因?yàn)槲医壎藘蓚€(gè)容器在相同的核上。

  
注意：為了顯示所有的屬性，你可以使用 systemctl show docker-4be96b853089bc6044b29cb873cac460b429cfcbdd0e877c0868eb2a901dbf80.scope 命令。為了列出所有可用的屬性，請(qǐng)看下 man systemd.resource-control。

你可以在 /sys/fs/cgroup/cpu/system.slice/docker-$FULL_CONTAINER_ID.scope/ 下面發(fā)現(xiàn)指定容器的關(guān)于 CPU 的所有信息，例如：

$ ls /sys/fs/cgroup/cpu/system.slice/docker-6935854d444d78abe52d629cb9d680334751a0cda82e11d2610e041d77a62b3f.scope/
cgroup.clone_children  cpuacct.usage_percpu  cpu.rt_runtime_us  tasks
cgroup.procs           cpu.cfs_period_us     cpu.shares
cpuacct.stat           cpu.cfs_quota_us      cpu.stat
cpuacct.usage          cpu.rt_period_us      notify_on_release

  
注意：關(guān)于這些文件的更多信息，請(qǐng)移步 RHEL Resource Management Guide 查看。

需要記住的一些事項(xiàng)：

CPU share 僅僅是一個(gè)數(shù)字 - 與 CPU 速度無關(guān)

新容器默認(rèn)有 1024 shares

在一臺(tái)空閑主機(jī)上，低 shares 的容器仍可以使用 100% 的 CPU

如果你想，你可以把容器固定到一個(gè)指定核

現(xiàn)在讓我看下限制內(nèi)存。

第一件事需要注意的是，默認(rèn)一個(gè)容器可以使用主機(jī)上的所有內(nèi)存。

如果你想為容器中的所有進(jìn)程限制內(nèi)存，使用 docker run 命令的 -m 開關(guān)即可。你可以使用 bytes 定義它的值或是（k， m 或 g）。

你可以像這樣使用 -m 開關(guān)：

$ docker run -it --rm -m 128m fedora bash

為了顯示限制的實(shí)際情況，我將再次使用我的 stress 鏡像?？紤]一下的運(yùn)行：

$ docker run -it --rm -m 128m stress --vm 1 --vm-bytes 128M --vm-hang 0
stress: info: [1] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd

stress 工具將創(chuàng)建一個(gè)進(jìn)程，并嘗試分配 128MB 內(nèi)存給它。它工作的很好，但是如果我們使用的比實(shí)際分配給容器的更多，將發(fā)生什么？

$ docker run -it --rm -m 128m stress --vm 1 --vm-bytes 200M --vm-hang 0
stress: info: [1] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd

它照樣正常工作，是不是很奇怪？是的，我同意。

我們將在 libcontainer 源碼 找到解釋（cgroups 的 Docker 接口）。我們可以看到源碼中默認(rèn)的 memory.memsw.limit_in_bytes 值是被設(shè)置成我們指定的內(nèi)存參數(shù)的兩倍，當(dāng)我們啟動(dòng)一個(gè)容器的時(shí)候。memory.memsw.limit_in_bytes 參數(shù)表達(dá)了什么？它是 memory 和 swap 的總和。這意味著 Docker 將分配給容器 -m 內(nèi)存值以及 -m swap 值。

當(dāng)前的 Docker 接口不允許我們指定（或者是完全禁用它）多少 swap 應(yīng)該被使用，所以我們現(xiàn)在需要一起使用它。

有了以上信息，我們可以再次運(yùn)行我們的示例。這次我們嘗試分配超過我們分配的兩倍內(nèi)存。它將使用所有的內(nèi)存和所有的 swap，然后玩完了。

$ docker run -it --rm -m 128m stress --vm 1 --vm-bytes 260M --vm-hang 0
stress: info: [1] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
stress: FAIL: [1] (415) <-- worker 6 got signal 9
stress: WARN: [1] (417) now reaping child worker processes
stress: FAIL: [1] (421) kill error: No such process
stress: FAIL: [1] (451) failed run completed in 5s

如果你嘗試再次分配比如 250MB（--vm-bytes 250M），它將工作的很好。

  
警告：如果你不通過 -m 開關(guān)限制內(nèi)存，swap 也被不會(huì)被限制1。

不限制內(nèi)存將導(dǎo)致將導(dǎo)致一個(gè)容器可以很容易使得整個(gè)系統(tǒng)不可用的問題。因此請(qǐng)記住要一直使用 -m 參數(shù)²。

你可以在 /sys/fs/cgroup/memory/system.slice/docker-$FULL_CONTAINER_ID.scope/ 下面發(fā)現(xiàn)關(guān)于內(nèi)存的所有信息，例如：

$ ls /sys/fs/cgroup/memory/system.slice/docker-48db72d492307799d8b3e37a48627af464d19895601f18a82702116b097e8396.scope/
cgroup.clone_children               memory.memsw.failcnt
cgroup.event_control                memory.memsw.limit_in_bytes
cgroup.procs                        memory.memsw.max_usage_in_bytes
memory.failcnt                      memory.memsw.usage_in_bytes
memory.force_empty                  memory.move_charge_at_immigrate
memory.kmem.failcnt                 memory.numa_stat
memory.kmem.limit_in_bytes          memory.oom_control
memory.kmem.max_usage_in_bytes      memory.pressure_level
memory.kmem.slabinfo                memory.soft_limit_in_bytes
memory.kmem.tcp.failcnt             memory.stat
memory.kmem.tcp.limit_in_bytes      memory.swappiness
memory.kmem.tcp.max_usage_in_bytes  memory.usage_in_bytes
memory.kmem.tcp.usage_in_bytes      memory.use_hierarchy
memory.kmem.usage_in_bytes          notify_on_release
memory.limit_in_bytes               tasks
memory.max_usage_in_bytes

  
注意：想了解關(guān)于這些文件的更多信息，請(qǐng)移步到 RHEL Resource Management Guide, memory section。

對(duì)于 塊設(shè)備，我們可以考慮兩種不同類型的限制：

讀寫速率

可寫的空間 (定額)

第一個(gè)是非常容易實(shí)施的，但是第二個(gè)仍未解決。

  
注意：我假設(shè)你正在使用 devicemapper storage 作為 Docker 的后端。使用其他后端，任何事情都將不是確定的。

Docker 沒有提供任何的開關(guān)來定義我們可以多快的讀或是寫數(shù)據(jù)到塊設(shè)備中。但是 CGroups 內(nèi)建了。它甚至通過 BlockIO* 屬性暴露給了 systemd。

為了限制讀寫速率我們可以分別使用 BlockIOReadBandwidth 和 BlockIOWriteBandwidth 屬性。

默認(rèn) bandwith 是沒有被限制的。這意味著一個(gè)容器可以使得硬盤”熱“，特別是它開始使用 swap 的時(shí)候。

讓我測(cè)試沒有執(zhí)行限制的速率：

$ docker run -it --rm --name block-device-test fedora bash
bash-4.2# time $(dd if=/dev/zero of=testfile0 bs=1000 count=100000 && sync)
100000+0 records in
100000+0 records out
100000000 bytes (100 MB) copied, 0.202718 s, 493 MB/s

real  0m3.838s
user  0m0.018s
sys   0m0.213s

花費(fèi)了 3.8秒來寫入 100MB 數(shù)據(jù)，大概是 26MB/s。讓我們嘗試限制一點(diǎn)磁盤的速率。

為了能調(diào)整容器可用的 bandwitch，我們需要明確的知道容器掛載的文件系統(tǒng)在哪里。當(dāng)你在容器里面執(zhí)行 mount 命令的時(shí)候，你可以發(fā)現(xiàn)它，發(fā)現(xiàn)設(shè)備掛載在 root 文件系統(tǒng)：

$ mount
/dev/mapper/docker-253:0-3408580-d2115072c442b0453b3df3b16e8366ac9fd3defd4cecd182317a6f195dab3b88 on / type ext4 (rw,relatime,context="system_u:object_r:svirt_sandbox_file_t:s0:c447,c990",discard,stripe=16,data=ordered)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev type tmpfs (rw,nosuid,context="system_u:object_r:svirt_sandbox_file_t:s0:c447,c990",mode=755)

[SNIP]

在我們的示例中是 /dev/mapper/docker-253:0-3408580-d2115072c442b0453b3df3b16e8366ac9fd3defd4cecd182317a6f195dab3b88。

你也可以使用 nsenter 得到這個(gè)值，像這樣：

$ sudo /usr/bin/nsenter --target $(docker inspect -f "{{ .State.Pid }}" $CONTAINER_ID) --mount --uts --ipc --net --pid mount | head -1 | awk "{ print $1 }"
/dev/mapper/docker-253:0-3408580-d2115072c442b0453b3df3b16e8366ac9fd3defd4cecd182317a6f195dab3b88

現(xiàn)在我們可以改變 BlockIOWriteBandwidth 屬性的值，像這樣：

$ sudo systemctl set-property --runtime docker-d2115072c442b0453b3df3b16e8366ac9fd3defd4cecd182317a6f195dab3b88.scope "BlockIOWriteBandwidth=/dev/mapper/docker-253:0-3408580-d2115072c442b0453b3df3b16e8366ac9fd3defd4cecd182317a6f195dab3b88 10M"

這應(yīng)該把磁盤的速率限制在 10MB/s，讓我們?cè)俅芜\(yùn)行 dd：

bash-4.2# time $(dd if=/dev/zero of=testfile0 bs=1000 count=100000 && sync)
100000+0 records in
100000+0 records out
100000000 bytes (100 MB) copied, 0.229776 s, 435 MB/s

real  0m10.428s
user  0m0.012s
sys   0m0.276s

可以看到，它花費(fèi)了 10s 來把 100MB 數(shù)據(jù)寫入磁盤，因此這速率是 10MB/s。

  
注意：你可以使用 BlockIOReadBandwidth 屬性同樣的限制你的讀速率

正如我前面提到的，這是艱難的話題，默認(rèn)你每個(gè)容器有 10GB 的空間，有時(shí)候它太大了，有時(shí)候不能滿足我們所有的數(shù)據(jù)放在這里。不幸的是，我們不能為此做點(diǎn)什么。

我們能做的唯一的事情就是新容器的默認(rèn)值，如果你認(rèn)為一些其他的值（比如 5GB）更適合你的情況，你可以通過指定 Docker daemon 的 --storage-opt來實(shí)現(xiàn)，像這樣：

docker -d --storage-opt dm.basesize=5G

你可以調(diào)整一些其他的東西，但是請(qǐng)記住，這需要在后面重起你的 Docker daemon，想了解更多的信息，請(qǐng)看這里。

你可以在 /sys/fs/cgroup/blkio/system.slice/docker-$FULL_CONTAINER_ID.scope/ 目錄下發(fā)現(xiàn)關(guān)于塊設(shè)備的所有信息，例如：

$ ls /sys/fs/cgroup/blkio/system.slice/docker-48db72d492307799d8b3e37a48627af464d19895601f18a82702116b097e8396.scope/
blkio.io_merged                   blkio.sectors_recursive
blkio.io_merged_recursive         blkio.throttle.io_service_bytes
blkio.io_queued                   blkio.throttle.io_serviced
blkio.io_queued_recursive         blkio.throttle.read_bps_device
blkio.io_service_bytes            blkio.throttle.read_iops_device
blkio.io_service_bytes_recursive  blkio.throttle.write_bps_device
blkio.io_serviced                 blkio.throttle.write_iops_device
blkio.io_serviced_recursive       blkio.time
blkio.io_service_time             blkio.time_recursive
blkio.io_service_time_recursive   blkio.weight
blkio.io_wait_time                blkio.weight_device
blkio.io_wait_time_recursive      cgroup.clone_children
blkio.leaf_weight                 cgroup.procs
blkio.leaf_weight_device          notify_on_release
blkio.reset_stats                 tasks
blkio.sectors

  
注意：想了解關(guān)于這些文件的更多信息，請(qǐng)移步到 RHEL Resource Management Guide, blkio section。

正如你所看到的，Docker 容器的資源管理是可行的。甚至非常簡(jiǎn)單。唯一的事情就是我們不能為磁盤使用設(shè)置一個(gè)定額，這有一個(gè)上游問題列表 -- 跟蹤它并且評(píng)論。

希望你發(fā)現(xiàn)我的文章對(duì)你有用。

這在技術(shù)上是不正確的； 這有限度, 但是它設(shè)置的值在我們當(dāng)前運(yùn)行的系統(tǒng)是不可達(dá)的。 例如在我的筆記本上 16GB 的內(nèi)存值是 18446744073709551615，這是 ~18.5 exabytes…??

或者是使用 MemoryLimit 屬性。??