docker容器資源配額控制

docker通過cgroup來控制容器使用的資源配額,包括CPU、內存、磁盤三大方面,基本覆蓋了常見的資源配額和使用量控制。

cgroup簡介

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

  1. blkio:設置限制每個塊設備的輸入輸出控制。例如:磁盤,光盤以及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

CPU資源配額控制

CPU份額控制

docker提供了–cpu-shares參數,在創建容器時指定容器所使用的CPU份額值。使用示例:

使用命令docker run -tid –cpu-shares 100 ubuntu:stress,創建容器,則最終生成的cgroup的cpu份額配置可以下面的文件中找到:

root@ubuntu:~# cat /sys/fs/cgroup/cpu/docker/<容器的完整長ID>/cpu.shares
100

cpu-shares的值不能保證可以獲得1個vcpu或者多少GHz的CPU資源,僅僅只是一個彈性的加權值。

默認情況下,每個docker 容器的cpu份額都是1024。單獨一個容器的份額是沒有意義的,只有在同時運行多個容器時,容器的cpu加權的效果才能體現出來。例如,兩個容器A、B 的cpu份額分別爲1000和500,在cpu進行時間片分配的時候,容器A比容器B多一倍的機會獲得CPU的時間片,但分配的結果取決於當時主機和其他 容器的運行狀態,實際上也無法保證容器A一定能獲得CPU時間片。比如容器A的進程一直是空閒的,那麼容器B是可以獲取比容器A更多的CPU時間片的。極 端情況下,比如說主機上只運行了一個容器,即使它的cpu份額只有50,它也可以獨佔整個主機的cpu資源。

cgroups只在容器分配的資源緊缺時,也就是說在需要對容器使用的資源進行限制時,纔會生效。因此,無法單純根據某個容器的cpu份額來確定有多少cpu資源分配給它,資源分配結果取決於同時運行的其他容器的cpu分配和容器中進程運行情況。

CPU週期控制

docker提供了–cpu-period–cpu-quota兩個參數控制容器可以分配到的CPU時鐘週期。–cpu-period是用來指定容器對CPU的使用要在多長時間內做一次重新分配,而–cpu-quota是用來指定在這個週期內,最多可以有多少時間用來跑這個容器。跟–cpu-shares不同的是這種配置是指定一個絕對值,而且沒有彈性在裏面,容器對CPU資源的使用絕對不會超過配置的值。

cpu-periodcpu-quota的單位爲微秒(μs)。cpu-period的最小值爲1000微秒,最大值爲1秒(10^6 μs),默認值爲0.1秒(100000 μs)。cpu-quota的值默認爲-1,表示不做控制。

舉個例子,如果容器進程需要每1秒使用單個CPU的0.2秒時間,可以將cpu-period設置爲1000000(即1秒),cpu-quota設置爲200000(0.2秒)。當然,在多核情況下,如果允許容器進程需要完全佔用兩個CPU,則可以將cpu-period設置爲100000(即0.1秒),cpu-quota設置爲200000(0.2秒)。

使用示例:

使用命令docker run -tid –cpu-period 100000 –cpu-quota 200000 ubuntu,創建容器,則最終生成的cgroup的cpu週期配置可以下面的文件中找到:

root@ubuntu:~# cat /sys/fs/cgroup/cpu/docker/<容器的完整長ID>/cpu.cfs_period_us
100000
root@ubuntu:~# cat /sys/fs/cgroup/cpu/docker/<容器的完整長ID>/cpu.cfs_quota_us
200000

關於cpu-sharescpu-periodcpu-quota這些配置的詳細介紹,大家可以深入閱讀RedHat文檔中關於CPU的這一章

CPU core控制

對多核CPU的服務器,docker還可以控制容器運行限定使用哪些cpu內核和內存節點,即使用–cpuset-cpus–cpuset-mems參數。對具有NUMA拓撲(具有多CPU、多內存節點)的服務器尤其有用,可以對需要高性能計算的容器進行性能最優的配置。如果服務器只有一個內存節點,則–cpuset-mems的配置基本上不會有明顯效果。

使用示例:

命令docker run -tid –name cpu1 –cpuset-cpus 0-2 ubuntu,表示創建的容器只能用0、1、2這三個內核。最終生成的cgroup的cpu內核配置如下:

root@ubuntu:~# cat /sys/fs/cgroup/cpuset/docker/<容器的完整長ID>/cpuset.cpus
0-2

通過docker exec <容器ID> taskset -c -p 1(容器內部第一個進程編號一般爲1),可以看到容器中進程與CPU內核的綁定關係,可以認爲達到了綁定CPU內核的目的。

CPU配額控制參數的混合使用

當上面這些參數中時,cpu-shares控制只發生在容器競爭同一個內核的時間片時,如果通過cpuset-cpus指定容器A使用內核0,容器B只是用內核1,在主機上只有這兩個容器使用對應內核的情況,它們各自佔用全部的內核資源,cpu-shares沒有明顯效果。

cpu-periodcpu-quota這兩個參數一般聯合使用,在單核情況或者通過cpuset-cpus強制容器使用一個cpu內核的情況下,即使cpu-quota超過cpu-period,也不會使容器使用更多的CPU資源。

cpuset-cpuscpuset-mems只在多核、多內存節點上的服務器上有效,並且必須與實際的物理配置匹配,否則也無法達到資源控制的目的。

在系統具有多個CPU內核的情況下,需要通過cpuset-cpus爲容器CPU內核才能比較方便地進行測試。

試用下列命令創建測試用的容器:

docker run -tid –name cpu2 –cpuset-cpus 3 –cpu-shares 512 ubuntu:stress stress -c 10
docker run -tid –name cpu3 –cpuset-cpus 3 –cpu-shares 1024 ubuntu:stress stress -c 10

上面的ubuntu:stress鏡像安裝了stress工具來測試CPU和內存的負載。兩個容器的命令stress -c 10&,這個命令將會給系統一個隨機負載,產生10個進程,每個進程都反覆不停的計算由rand()產生隨機數的平方根,直到資源耗盡。

觀察到宿主機上的CPU試用率如下圖所示,第三個內核的使用率接近100%,並且一批進程的CPU使用率明顯存在2:1的使用比例的對比

容器cpu2的CPU使用如下所示:quota02

容器cpu2的CPU使用如下所示:

quota03

容器cpu3的CPU使用如下圖示:

quota04

分別進入容器後,使用top命令可以明顯地看出容器之間的資源使用對比,並且也達到了綁定CPU內核的目的。

注意:如果使用 nsenter之類的工具進入容器,再使用stress -c 10進行測試,就可以發現cpuset-cpus的限制是可以被突破的,從而使stress測試進程使用宿主機的所有CPU內核。這是因爲nsenter 使用掛載的方式直接進入了容器的命名空間,突破了命名空間中的cgroup控制。

內存配額控制

和CPU控制一樣,docker也提供了若干參數來控制容器的內存使用配額,可以控制容器的swap大小、可用內存大小等各種內存方面的控制。主要有以下參數:

  • memory-swappiness: 控制進程將物理內存交換到swap分區的傾向,默認係數爲60。係數越小,就越傾向於使用物理內存。值範圍爲0-100。當值爲100時,表示儘量使用 swap分區;當值爲0時,表示禁用容器 swap 功能(這點不同於宿主機,宿主機 swappiness 設置爲 0 也不保證 swap 不會被使用)。

  • –kernel-memory:內核內存,不會被交換到swap上。一般情況下,不建議修改,可以直接參考docker的官方文檔。

  • –memory:設置容器使用的最大內存上限。默認單位爲byte,可以使用K、G、M等帶單位的字符串。

  • –memory-reservation:啓用彈性的內存共享,當宿主機資源充足時,允許容器儘量多地使用內存,當檢測到內存競爭或者低內存時,強制將容器的內存降低到memory-reservation所指定的內存大小。按照官方說法,不設置此選項時,有可能出現某些容器長時間佔用大量內存,導致性能上的損失。

  • –memory-swap:等於內存和swap分區大小的總和,設置爲-1時,表示swap分區的大小是無限的。默認單位爲byte,可以使用K、G、M等帶單位的字符串。如果–memory-swap的設置值小於–memory的值,則使用默認值,爲–memory-swap值的兩倍

默認情況下,容器可以使用主機上的所有空閒內存。

與CPU的cgroups配置類似,docker會自動爲容器在目錄/sys/fs/cgroup/memory/docker/<容器的完整長ID>中創建相應cgroup配置文件,例如下面的文件:

quota05

這些文件與docker的相關配置是一一對應的,可以參考RedHat的文檔Resource_Management_Guide的內存部分來查看它們的作用。

內存配額控制使用示例

設置容器的內存上限,參考命令如下所示:

docker run -tid —name mem1 —memory 128m ubuntu:stress /bin/bash

默認情況下,除了–memory指定的內存大小以外,docker還爲容器分配了同樣大小的swap分區,也就是說,上面的命令創建出的容器實際上最多可以使用256MB內存,而不是128MB內存。如果需要自定義swap分區大小,則可以通過聯合使用–memory–swap參數來實現控制。

對上面的命令創建的容器,可以查看到在cgroups的配置文件中,查看到容器的內存大小爲128MB (128×1024×1024=134217728B),內存和swap加起來大小爲256MB (256×1024×1024=268435456B)。

cat /sys/fs/cgroup/memory/docker/<容器的完整ID>/memory.limit_in_bytes
134217728
cat /sys/fs/cgroup/memory/docker/<容器的完整ID>/memory.memsw.limit_in_bytes
268435456

注意:執行上述命令時,命令行可能會輸出下面的警告:

WARNING: Your kernel does not support swap limit capabilities, memory limited without swap.

這是因爲主機上默認不啓用cgroup來控制swap分區,可以參考docker官方的相應文檔,修改grub啓動參數。

在容器中,依次使用下面的stress命令,即可對容器的內存進行壓力測試,確認內存。

stress –vm 1 –vm-bytes 256M –vm-hang 0 &
stress –vm 1 –vm-bytes 250M –vm-hang 0 &

quota06

可以發現,使用256MB進行壓力測試時,由於超過了內存上限(128MB內存+128MB swap),進程被OOM殺死。使用250MB進行壓力測試時,進程可以正常運行,並且通過docker stats可以查看到容器的內存已經滿負載了。

quota07

磁盤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

最終輸出如下圖所示:

quota08

在我的測試環境上沒有達到理想的測試效果,通過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來驗證寫速度,輸出如下圖示:

quota09

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

容器空間大小限制

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

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章