1. 程式人生 > >Docker系列09—Docker的系統資源限制及驗證

Docker系列09—Docker的系統資源限制及驗證

stat 意義 class 內存交換 詳細信息 test 禁用 優先級 單獨

1、限制容器的資源

  默認情況下,容器沒有資源限制,可以使用主機內核調度程序允許的盡可能多的給定資源。Docker提供了控制容器可以使用多少內存或CPU的方法,設置docker run命令的運行時配置標誌。本篇提供有關何時應設置此類限制的詳細信息以及設置這些限制的可能含義。

  其中許多功能都要求您的內核支持Linux功能。要檢查支持,可以使用該 docker info命令。如果內核中禁用了某項功能,您可能會在輸出結尾處看到一條警告,如下所示:WARNING: No swap limit support,請參閱操作系統的文檔以啟用它們,了解更多

[root@along ~]# docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 43
Server Version: 17.03.2-ce
Storage Driver: overlay
 Backing Filesystem: xfs
 Supports d_type: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 4ab9917febca54791c5f071a9d1f404867857fcc
runc version: 54296cf40ad8143b62dbcaa1d90e520a2136ddfe
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 3.10.0-514.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 976.5 MiB
Name: along
ID: KGWA:GDGT:PTK7:PAX4:A3JZ:LV6N:U5QD:UQCY:AGZV:P32E:V73T:JJHR
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: alongedu
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 docker2:80
 127.0.0.0/8
Registry Mirrors:
 https://registry.docker-cn.com
Live Restore Enabled: false

2、內存

2.1 內存不足的風險

  重要的是不要讓正在運行的容器占用太多的主機內存。在Linux主機上,如果內核檢測到沒有足夠的內存來執行重要的系統功能,它會拋出一個OOME 或者 Out Of Memory Exception,並開始查殺進程以釋放內存任何進程都會被殺死,包括Docker和其他重要的應用程序。如果錯誤的進程被殺死,這可以有效地降低整個系統。

  Docker嘗試通過調整Docker守護程序上的OOM優先級來降低這些風險,以便它比系統上的其他進程更不可能被殺死。容器上的OOM優先級未調整。這使得單個容器被殺死的可能性比Docker守護程序或其他系統進程被殺死的可能性更大。您不應試圖通過

--oom-score-adj 在守護程序或容器上手動設置為極端負數或通過設置容器來繞過這些安全措施--oom-kill-disable

  有關Linux內核的OOM管理的更多信息,請參閱內存不足管理

  您可以通過以下方式降低OOME導致系統不穩定的風險:

  • 在將應用程序投入生產之前,請執行測試以了解應用程序的內存要求。
  • 確保您的應用程序僅在具有足夠資源的主機上運行。
  • 限制容器可以使用的內存量,如下所述。
  • Docker主機上配置交換時要小心。交換比內存更慢且性能更低,但可以提供緩沖以防止系統內存耗盡。
  • 考慮將容器轉換為服務,並使用服務級別約束和節點標簽來確保應用程序僅在具有足夠內存的主機上運行

2.2 限制容器對內存設有的設置

  Docker可以強制執行硬內存限制,允許容器使用不超過給定數量的用戶或系統內存或軟限制,這允許容器使用盡可能多的內存,除非滿足某些條件,例如內核檢測到主機上的低內存或爭用。當單獨使用或設置了多個選項時,其中一些選項會產生不同的效果。

  大部分的選項取正整數,跟著一個後綴bk mg,,表示字節,千字節,兆字節或千兆字節。

選項

描述

-m or --memory=

容器可以使用的最大內存量。如果設置此選項,則允許的最小值為4m

--memory-swap*

允許此容器交換到磁盤的內存量。

--memory-swappiness

默認情況下,主機內核可以交換容器使用的匿名頁面的百分比。您可以設置--memory-swappiness 0100之間的值,以調整此百分比。

--memory-reservation

允許您指定小於軟件限制的軟限制--memory,當Docker檢測到主機上的爭用或內存不足時,該限制將被激活。如果使用--memory-reservation,則必須將其設置為低於--memory 優先級。因為它是軟限制,所以不保證容器不超過限制。

--kernel-memory

容器可以使用的最大內核內存量。允許的最小值是4m。由於內核內存無法換出,因此內核內存不足的容器可能會阻塞主機資源,這可能會對主機和其他容器產生副作用。

--oom-kill-disable

默認情況下,如果發生內存不足(OOM)錯誤,內核會終止容器中的進程。要更改此行為,請使用該--oom-kill-disable選項。僅在已設置-m/--memory 選項的容器上禁用OOM殺手。如果-m 未設置該標誌,則主機可能會耗盡內存,並且內核可能需要終止主機系統的進程才能釋放內存。

2.2.1 --memory-swap 設置

1)介紹

  --memory-swap 是一個修飾符標誌,只有在--memory 設置時才有意義。使用swap允許容器在容器耗盡可用的所有RAM時將多余的內存需求寫入磁盤。對於經常將內存交換到磁盤的應用程序,性能會受到影響。

2)它的設置會產生復雜的效果:

  • 如果--memory-swap 設置為正整數,那麽這兩個--memory--memory-swap 必須設置。--memory-swap 表示可以使用的memory and swap,並--memory 控制非交換內存(物理內存)使用的量。所以如果--memory="300m" --memory-swap="1g",容器可以使用300米的內存和700米(1g - 300mswap
  • 如果--memory-swap 設置為0,則忽略該設置,並將該值視為未設置。
  • 如果--memory-swap 設置為與值相同的值--memory,並且--memory設置為正整數,則容器無權訪問swap。請參考下面阻止容器使用交換。
  • 如果--memory-swap 未設置--memory 設置,則容器可以使用兩倍於--memory設置swap,主機容器需要配置有swap。例如,如果設置--memory="300m" --memory-swap 未設置,容器可以使用300米的內存和600米的swap
  • 如果--memory-swap 明確設置為-1,則允許容器使用無限制swap,最多可達宿主機系統上可用的數量
  • 在容器內部,工具如free 報告主機的swap,而不是容器內真正可用的內存。不要依賴free 或類似工具來確定是否存在swap

3)防止容器使用交換

  如果--memory --memory-swap設置為相同的值,則可以防止容器使用swap。這是因為--memory-swap 可以使用的memory and swap,而--memory只是可以使用的物理內存量。

2.2.2 --memory-swappiness 設置

  • 值為0將關閉匿名頁面交換。
  • 100將所有匿名頁面設置為可交換。
  • 默認情況下,如果未設置--memory-swappiness,則值將從主機繼承。

2.2.3 --kernel-memory 設置

1)介紹

內核內存限制以分配給容器的總內存表示。請考慮以下方案:

  • 無限內存,無限內核內存:這是默認設置。
  • 無限內存,有限的內核內存:當所有cgroup所需的內存量大於主機上實際存在的內存量時,這是合適的。您可以將內核內存配置為永遠不會覆蓋主機上可用的內容,而需要更多內存的容器需要等待它。
  • 有限的內存,無限的內核內存:整體內存有限,但內核內存不受限制。
  • 有限的內存,有限的內核內存:限制用戶和內核內存對於調試與內存相關的問題非常有用。如果容器使用意外數量的任一類型的內存,則內存不足而不會影響其他容器或主機。在此設置中,如果內核內存限制低於用戶內存限制,則內核內存不足會導致容器遇到OOM錯誤。如果內核內存限制高於用戶內存限制,則內核限制不會導致容器遇到OOM

當您打開任何內核內存限制時,主機會根據每個進程跟蹤高水位線統計信息,因此您可以跟蹤哪些進程(在本例中為容器)正在使用多余的內存。通過/proc/<PID>/status在主機上查看,可以在每個過程中看到這一點。

3CPU

  • 默認情況下,每個容器對主機CPU周期的訪問權限是不受限制的
  • 您可以設置各種約束來限制給定容器訪問主機的CPU周期。
  • 大多數用戶使用和配置 默認CFS調度程序。
  • Docker 1.13及更高版本中,您還可以配置 實時調度程序。

3.1 配置默認CFS調度程序

  CFS是用於普通Linux進程的Linux內核CPU調度程序。多個運行時標誌允許您配置容器具有的CPU資源訪問量。使用這些設置時,Docker會修改主機上容器的cgroup的設置。

選項

描述

--cpus=<value>

指定容器可以使用的可用CPU資源量。例如,如果主機有兩個CPU並且你已設置--cpus="1.5",則容器最多保證一個半CPU。這相當於設置--cpu-period="100000" --cpu-quota="150000"。可在Docker 1.13及更高版本中使用。

--cpu-period=<value>

指定CPU CFS調度程序周期,它與並用 --cpu-quota。默認為100微秒。大多數用戶不會更改默認設置。如果您使用Docker 1.13或更高版本,請--cpus 使用。

--cpu-quota=<value>

對容器施加CPU CFS配額。--cpu-period限制前容器限制為每秒的微秒數。作為有效上限。如果您使用Docker 1.13或更高版本,請--cpus改用。

--cpuset-cpus

限制容器可以使用的特定CPU或核心。如果您有多個CPU,則容器可以使用逗號分隔列表或連字符分隔的CPU範圍。第一個CPU編號為0.有效值可能是0-3(使用第一個,第二個,第三個和第四個CPU)或1,3(使用第二個和第四個CPU)。

--cpu-shares

將此標誌設置為大於或小於默認值1024的值,以增加或減少容器的重量,並使其可以訪問主機的CPU周期的較大或較小比例。僅在CPU周期受限時才會強制執行此操作。當有足夠的CPU周期時,所有容器都會根據需要使用盡可能多的CPU。這樣,這是一個軟限制。--cpu-shares不會阻止容器以群集模式進行調度。它為可用的CPU周期優先考慮容器CPU資源。它不保證或保留任何特定的CPU訪問權限。

4、操作演示

4.1 準備工作

1)先查詢宿主機的資源:

[root@docker ~]# lscpu   CPU資源
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             4
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 60
Model name:            Intel(R) Xeon(R) CPU E3-1231 v3 @ 3.40GHz
Stepping:              3
CPU MHz:               3395.854
BogoMIPS:              6792.17
Hypervisor vendor:     VMware
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              8192K
NUMA node0 CPU(s):     0-3
[root@docker ~]# free -h   內存、swap資源
              total        used        free      shared  buff/cache   available
Mem:           7.8G        193M        7.2G        8.6M        438M        7.3G
Swap:          2.0G        400K        2.0G

  

2)在dockerhub 下載一個用於壓測的鏡像

[root@docker ~]# docker pull lorel/docker-stress-ng

  

3)該壓測鏡像的使用方法

[root@docker ~]# docker run --name stress --rm lorel/docker-stress-ng:latest stress --help

使用--help 可以查詢此壓測鏡像的用法

例:

    stress-ng --cpu 8 --io 4 --vm 2 --vm-bytes 128M --fork 4 --timeout 10s

語法:

  • -c N, --cpu N 啟動N個子進程(cpu
  • --vm N 啟動N個進程對內存進行壓測
  • --vm-bytes 128M 每個子進程使用多少內存(默認256M

4.2 測試內存限制

1)現在最大使用內存啟動容器

[root@docker ~]# docker run --name stress --rm -m 256m lorel/docker-stress-ng:latest stress --vm 2
stress-ng: info: [1] defaulting to a 86400 second run per stressor
stress-ng: info: [1] dispatching hogs: 2 vm

[root@docker ~]# docker stats stress
CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT   MEM %               NET I/O             BLOCK I/O           PIDS
e1fdb0520bad        stress              8.22%               254MiB / 256MiB     99.22%              648B / 0B           46.9MB / 3.63GB     5

註釋:

  • -m 256m 限制此容器最大只能使用256m 內存;
  • --vm 2 啟動壓測容器,使用256x2=512m的內存;
  • docker stats 結果查詢,容器實際使用內存不能超過256m

4.3 測試CPU限制

1)限制最大使用2CPU

[root@docker ~]# docker run --name stress --rm --cpus 2 lorel/docker-stress-ng:latest stress --cpu 8
stress-ng: info: [1] defaulting to a 86400 second run per stressor
stress-ng: info: [1] dispatching hogs: 8 cpu

[root@docker ~]# docker stats stress
CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
ca86c0de6431        stress              199.85%             15.81MiB / 7.781GiB   0.20%               648B / 0B           0B / 0B             9

  

2)不限制使用CPU核數

[root@docker ~]# docker run --name stress --rm lorel/docker-stress-ng:latest stress --cpu 8
stress-ng: info: [1] defaulting to a 86400 second run per stressor
stress-ng: info: [1] dispatching hogs: 8 cpu

[root@docker ~]# docker stats stress
CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
167afeac7c97        stress              399.44%             15.81MiB / 7.781GiB   0.20%               508B / 0B           0B / 0B             9

Docker系列09—Docker的系統資源限制及驗證