Docker 通过 cgroups 自动控制容器 CPU、内存、IO 资源配额。内存用 –memory 设硬限制（映射 memory.max），建议禁用 swap；CPU 用 –cpus 实现精确配额（映射 cpu.max）或 –cpu-shares 做权重分配；IO 支持 –device-read-bps 和 –blkio-weight 限速。验证须查 /sys/fs/cgroup 下对应文件，而非仅依赖 docker inspect。
限制 Docker 容器的资源使用，本质就是通过 cgroups 控制进程组的 CPU、内存、IO 等资源配额。Docker 在启动时自动创建并配置对应 cgroup 子系统，无需手动挂载或写 cgroup 文件，但理解底层机制能帮你精准调优和排查问题。
内存限制：避免 OOM 与合理预留
Docker 用–memory（如-m 512m）设置容器可用内存上限，该值会映射到 cgroup v2 的memory.max（v1 为memory.limit_in_bytes）。超过限制后，内核 OOM Killer 可能杀掉容器内主进程。
- 建议同时设置 –memory-swap=0 禁用 swap，避免内存压力下性能骤降
- 若需预留缓冲空间，可设–memory-reservation（软限制），它不强制但影响 cgroup 内存回收优先级
- 查看实际使用：运行中执行 docker stats <container>，或进入容器查/sys/fs/cgroup/memory.max 和/sys/fs/cgroup/memory.current
CPU 配额：按权重或硬限制分配
Docker 提供两种 CPU 控制方式：–cpus（如–cpus=1.5）适用于大多数场景，它基于 cgroup v2 的cpu.max（v1 为cpu.cfs_quota_us/cpu.cfs_period_us），实现精确的毫秒级时间片分配。
- 若宿主机 CPU 核心数少，慎用 –cpus 小数值（如 0.1），可能导致调度延迟；此时改用–cpu-shares（默认 1024）做相对权重分配更稳妥
- 绑定特定 CPU 核心？用–cpuset-cpus=”0-1″，对应 cgroup 的cpuset.cpus，适合 NUMA 敏感型应用
- 验证是否生效：容器内运行cat /sys/fs/cgroup/cpu.max，应显示类似150000 100000（表示 1.5 个核）
IO 限速：控制磁盘吞吐与 IOPS
对存储密集型容器（如数据库），需限制其 IO 抢占行为。Docker 支持块设备级限速，依赖 cgroup v2 的 io.max 或 v1 的blkio.weight/blkio.throttle.*。
- 按设备限速：用 –device-read-bps /dev/sda:10mb 限制读带宽，底层写入io.max（格式：major:minor rbps）
- 按权重分配 IO：–blkio-weight 300（范围 10–1000），仅在多个容器竞争同一设备时生效
- 注意：限速只对直接 IO 有效；若容器内应用使用 page cache，需配合内存限制才能真正压测 IO 瓶颈
验证与调试：别只信 docker inspect
docker inspect只显示启动参数，无法反映实时 cgroup 状态。真正判断限制是否生效，必须进 cgroup 路径看原始值。
- 找到容器 cgroup 路径：docker inspect -f ‘{{.State.Pid}}’ <container>，再查 /proc/<pid>/cgroup 定位子系统挂载点
- cgroup v2 统一挂载在 /sys/fs/cgroup/ 下，路径通常为/sys/fs/cgroup/docker/<short-id>
- 关键文件：查看 memory.max、cpu.max、io.max 确认配置；读 memory.current、cpu.stat 观察实际使用
不复杂但容易忽略：容器重启后 cgroup 重置，所有限制自动恢复；临时修改 cgroup 文件仅本次生效，且 Docker 守护进程可能覆盖。生产环境务必通过 docker run 参数或 compose 文件固化配置。
