Docker的系统资源限制及验证

时间 2019-11-06

原文原文链接

1 、限制容器的资源

默认状况下， 容器没有资源限制 ，可使用主机内核调度程序容许的尽量多的给定资源。 Docker 提供了控制容器能够 使用多少内存或 CPU 的方法 ，设置 docker run 命令的运行时配置标志。本篇提供有关什么时候应设置此类限制的详细信息以及设置这些限制的可能含义。html

其中许多功能都要求您的 内核支持 Linux 功能 。要检查支持，可使用该 docker info 命令。若是内核中禁用了某项功能，您可能会在输出结尾处看到一条警告，以下所示： WARNING: No swap limit support ，请参阅操做系统的文档以启用它们，了解更多。java

[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 和其余重要的应用程序。若是错误的进程被杀死，这能够有效地下降整个系统。node

Docker 尝试经过调整 Docker 守护程序上的 OOM 优先级 来下降这些风险， 以便它比系统上的其余进程更不可能被杀死 。容器上的 OOM 优先级未调整。这使得单个容器被杀死的可能性比 Docker 守护程序或其余系统进程被杀死的可能性更大。您不该试图经过 --oom-score-adj 在守护程序或容器上手动设置为极端负数或经过设置容器来绕过这些安全措施 --oom-kill-disable 。linux

有关 Linux 内核的 OOM 管理的更多信息，请参阅内存不足管理。sql

您能够经过如下方式下降 OOME 致使系统不稳定的风险：docker

在将应用程序投入生产以前，请执行测试以了解应用程序的内存要求。
确保您的应用程序 仅在具备足够资源 的主机上运行。
限制容器可使用的内存量 ，以下所述。
在 Docker 主机上配置交换时要当心。交换比内存更慢且性能更低，但能够 提供缓冲 以防止系统内存耗尽。
考虑将容器转换为服务，并使用服务级别约束和节点标签来确保应用程序仅在具备足够内存的主机上运行

2.2 限制容器对内存设有的设置

Docker 能够 强制执行硬内存限制 ，容许容器使用不超过给定数量的用户或系统内存或软限制，这容许容器使用尽量多的内存，除非知足某些条件，例如内核检测到主机上的低内存或争用。当单独使用或设置了多个选项时，其中一些选项会产生不一样的效果。json

大部分的选项取正整数，跟着一个后缀 b ， k ， m ， g ，，表示字节，千字节，兆字节或千兆字节。安全

选项	描述
-m or --memory=	容器可使用的最大内存量。若是设置此选项，则容许的最小值为 4m 。架构
--memory-swap*	容许此容器交换到磁盘的内存量。并发
--memory-swappiness	默认状况下，主机内核能够交换容器使用的匿名页面的百分比。您能够设置 --memory-swappiness 0 到 100 之间的值，以调整此百分比。
--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 - 300m ） swap 。
若是 --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 在主机上查看，能够在每一个过程当中看到这一点。

3 、 CPU

默认状况下，每一个容器对主机 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 ）限制最大使用 2 核 CPU

[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

欢迎欢迎学Java的朋友们加入java架构交流： 855835163 群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用本身每一分每一秒的时间来学习提高本身，不要再用"没有时间“来掩饰本身思想上的懒惰！趁年轻，使劲拼，给将来的本身一个交代！