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文件固化配置。
