4. Docker资源限制：CPU/内存/磁盘IO限制配置、cgroups原理、资源耗尽场景模拟与排查、OOM Killer分析与预防

4.1 资源限制核心机制：cgroups

Docker 的资源隔离与限制能力源自 Linux 内核的 cgroups（Control Groups） 机制。cgroups 允许将进程分组，并对组的资源使用（CPU、内存、磁盘 I/O、网络等）进行精确的配额、计量与控制。Docker 为每个容器创建独立的 cgroup，从而实现“容器不抢宿主机资源”的承诺。

关键概念： cgroups v1 与 v2 并存。主流 Linux 发行版（如 CentOS 7/8、Ubuntu 20.04+）已逐步迁移至 cgroups v2。Docker 20.10+ 默认使用 cgroups v2，提供更统一的资源控制接口。
cgroups 层级结构与 Docker 资源限制映射 宿主机 cgroup 根 cpu 子系统 memory 子系统 blkio 子系统 其他子系统 docker/ 容器组 kubepods/ 容器组 system.slice/ 系统组 容器 A (ID: abc) 容器 B (ID: def) 说明： 每个容器在 cpu、memory、blkio 等子系统下都有独立的控制组。Docker 通过 --cpus、--memory 等参数写入对应 cgroup 文件，内核强制执行。

4.2 CPU 资源限制配置与排查

4.2.1 限制方式

参数 说明 示例
--cpus 限制容器可使用的 CPU 核心数（支持小数） --cpus=1.5
--cpu-shares 设置 CPU 相对权重（默认 1024），仅在 CPU 竞争时生效 --cpu-shares=512
--cpuset-cpus 绑定容器到指定物理 CPU 核心 --cpuset-cpus=0-3
--cpu-quota / --cpu-period CFS 配额：在 period（默认 100ms）内最多使用 quota 微秒 CPU 时间 --cpu-quota=50000 --cpu-period=100000（0.5 核）

4.2.2 验证与排查命令

# 查看容器 cgroup CPU 配置
docker inspect <container_id> --format '{{.HostConfig.CpuShares}} {{.HostConfig.NanoCpus}}'

# 直接读取 cgroup 文件（cgroups v2）
cat /sys/fs/cgroup/system.slice/docker-<container_id>.scope/cpu.max

# 实时监控容器 CPU 使用
docker stats <container_id> --no-stream

# 压力测试工具（容器内安装 stress-ng）
docker exec -it <container_id> stress-ng --cpu 4 --timeout 30s
排查要点： 当容器 CPU 使用率持续接近限制值时，应检查应用线程池配置是否合理、是否存在死循环或频繁 GC。使用 top -H -p <pid> 或 perf top 定位热点函数。

4.3 内存资源限制配置与 OOM Killer

4.3.1 内存限制参数

参数 说明 示例
--memory / -m 硬限制：容器最大可用内存 --memory=512m
--memory-reservation 软限制：当宿主机内存紧张时，尽力保证不超过此值 --memory-reservation=256m
--memory-swap 内存+交换分区总限制（默认与 memory 相同，即禁用 swap） --memory-swap=1g
--memory-swappiness 控制容器使用 swap 的倾向（0~100，默认继承宿主机） --memory-swappiness=0

4.3.2 OOM Killer 机制与预防

当容器内存使用超过 --memory 硬限制时，Linux 内核的 OOM Killer 会介入，选择并杀死容器内的进程以释放内存。Docker 默认会重启被 OOM 杀死的容器（--restart=always 时），但频繁 OOM 会导致服务抖动。

OOM 排查步骤：
  1. 使用 dmesg -T | grep -i "oom\|killed" 查看内核日志，确认 OOM 事件及被杀进程 PID。
  2. 使用 docker inspect <container_id> --format '{{.State.OOMKilled}}' 判断容器是否因 OOM 退出。
  3. 分析容器内应用内存占用：docker exec <container_id> cat /proc/1/status | grep VmRSS。
  4. 检查 JVM/Node.js 等运行时堆内存配置是否超出容器限制。

4.3.3 OOM 预防策略

  • 设置合理的内存限制： 根据压测结果，预留 20%~30% 的缓冲空间。
  • 配置 JVM 感知容器内存： 使用 -XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0（JDK 10+）。
  • 启用内存软限制： --memory-reservation 在宿主机内存压力下提前触发限制。
  • 调整 OOM 优先级： 通过 --oom-score-adj（-1000~1000）降低关键进程被 OOM 杀死的概率。
  • 监控与告警： 当容器内存使用超过 80% 限制时触发告警。
OOM Killer 触发流程与排查路径 容器内存超过 --memory 限制 内核 OOM Killer 被触发 选择 oom_score 最高的进程 进程被 SIGKILL 杀死 容器退出（Exit 137） 排查命令：dmesg -T | grep -i oom | tail -5 | docker inspect --format '{{.State.OOMKilled}}' <container_id>

4.4 磁盘 I/O 资源限制配置

4.4.1 限制参数

参数 说明 示例
--device-read-bps 限制设备读吞吐量（字节/秒） --device-read-bps=/dev/sda:10mb
--device-write-bps 限制设备写吞吐量（字节/秒） --device-write-bps=/dev/sda:10mb
--device-read-iops 限制设备读 IOPS --device-read-iops=/dev/sda:1000
--device-write-iops 限制设备写 IOPS --device-write-iops=/dev/sda:1000

4.4.2 验证与排查

# 查看容器 blkio cgroup 配置（cgroups v1）
cat /sys/fs/cgroup/blkio/docker/<container_id>/blkio.throttle.read_bps_device

# 使用 iostat 监控磁盘 I/O（宿主机）
iostat -x 1 /dev/sda

# 容器内模拟 I/O 压力
docker exec -it <container_id> dd if=/dev/zero of=/tmp/test bs=1M count=1000 oflag=direct
I/O 瓶颈排查： 当应用响应变慢但 CPU/内存使用正常时，应检查磁盘 I/O。使用 iotop 查看进程级 I/O 占用，blktrace 分析 I/O 延迟分布。数据库类容器（MySQL、PostgreSQL）对磁盘 I/O 敏感，建议使用本地 SSD 并合理设置 IOPS 限制。

4.5 资源耗尽场景模拟与排查实战

4.5.1 模拟场景清单

场景 模拟工具 预期现象 排查命令
CPU 耗尽 stress-ng --cpu 4 容器 CPU 使用率 100%，宿主机负载升高 docker stats, top
内存耗尽 stress-ng --vm 2 --vm-bytes 512M 容器 OOMKilled，退出码 137 dmesg, docker inspect
磁盘 I/O 耗尽 fio --rw=write --bs=4k --size=1G 磁盘 I/O 延迟飙升，应用写入超时 iostat -x, iotop
磁盘空间耗尽 dd if=/dev/zero of=/tmp/fill bs=1M 容器内写操作失败，报错 "No space left on device" df -h, docker system df
inode 耗尽 for i in $(seq 1 100000); do touch /tmp/$i; done 无法创建新文件，即使磁盘空间充足 df -i

4.5.2 排查方法论

  1. 全局视角： 使用 docker stats 查看所有容器资源使用概览。
  2. 容器内视角： docker exec <container_id> top、free -m、df -h。
  3. 宿主机视角： htop、iostat -x 1、vmstat 1、dmesg -T。
  4. cgroup 直接查看： 读取 /sys/fs/cgroup/<subsystem>/docker/<container_id>/ 下的文件。
  5. 日志分析： docker logs --tail 100 <container_id> 查看应用日志中的错误堆栈。
实战案例： 某 Java 微服务容器频繁重启，docker inspect 显示 OOMKilled: true。排查发现 JVM 未启用容器感知，-Xmx 设置为 2GB，但容器内存限制仅为 1GB。解决方案：升级 JDK 11+，使用 -XX:+UseContainerSupport -XX:MaxRAMPercentage=80.0，并将容器内存限制调整为 2.5GB。

4.6 最佳实践与总结

资源类型 推荐配置策略 监控指标 告警阈值
CPU 使用 --cpus 设置硬限制，--cpu-shares 设置权重 CPU 使用率、节流时间 持续 5 分钟 > 80%
内存 硬限制 + 软限制 + JVM 容器感知 内存使用率、OOM 事件 内存使用率 > 80% 或 OOM 计数 > 0
磁盘 I/O 根据压测结果设置 IOPS/BPS 限制 I/O 延迟、IOPS、吞吐量 平均延迟 > 50ms
磁盘空间 使用数据卷 + 定期清理 使用率、inode 使用率 使用率 > 85%

资源限制是 Docker 生产环境稳定运行的基石。理解 cgroups 原理、掌握限制配置方法、熟练使用排查工具，并建立完善的监控告警体系，才能有效预防和快速定位资源耗尽问题。

← 上一章 📖 返回目录 下一章 →