Docker资源配额核心是映射cgroups v2控制文件，--cpus设硬限（如1.2核对应cpu.max=120000 100000），--cpu-shares仅争用时按权重分配；--memory为内存硬上限，需配合--memory-swap禁用swap防延迟；IO限速须用--device-read-bps或--blkio-weight，并进容器查/sys/fs/cgroup/xxx验证真实状态。
在 Docker 中配置容器资源配额，核心是用好 --cpus、--memory、--device-read-bps 等参数，它们背后直接映射到 Linux cgroups v2 的底层控制文件。不理解这个映射关系，就容易只看 docker inspect 误以为限制生效，实际却没起作用。
CPU 配额：按需选硬限或权重
对大多数服务，优先用 --cpus（如 --cpus=1.2），它基于 cgroup v2 的 cpu.max，每 100ms 周期最多分配 120ms CPU 时间，效果稳定可预期。
- 小数值（如 0.1）可能因调度粒度导致响应延迟，此时改用 --cpu-shares 更合适——它不设上限，只在多个容器争抢 CPU 时按比例分配（默认 1024，设为 512 就是减半权重）
- 需要绑定物理核？加 --cpuset-cpus="0-2"，对应
cpuset.cpus，适合 NUMA 架构或低延迟场景 - 验证是否生效：进容器执行
cat /sys/fs/cgroup/cpu.max，输出应为类似120000 100000
内存限制：硬上限 + 关闭 swap 是关键
--memory（如 -m 512m）设的是硬上限，超出即触发 OOM Killer 杀进程。但很多人忽略 --memory-swap 的配合：
-
--memory=512m --memory-swap=512m：完全禁用 swap，推荐生产环境使用 -
--memory=512m --memory-swap=1g：允许最多 512MB swap，会带来不可控延迟 - 想留缓冲空间？加 --memory-reservation=384m，它不强制限制，只提升内存紧张时的回收优先级
- 验证：查
/sys/fs/cgroup/memory.max和memory.current，比docker stats更真实
IO 限速：按设备或按权重分场景
数据库类 IO 密集型容器必须限速，否则会拖垮整台宿主机磁盘性能：
- 要精确控速：用 --device-read-bps /dev/sda:5mb，底层写入
io.max，格式为major:minor rbps - 多容器共用一块盘？用 --blkio-weight 300（范围 10–1000），仅在竞争时生效
- 注意：IO 限速对 page cache 无效，若应用大量缓存读写，需同步压测内存限制才能暴露真实瓶颈
- 验证：进容器看
/sys/fs/cgroup/io.max或宿主机上iotop -p $(cat /proc/$(docker inspect -f '{{.State.Pid}}' CONTAINER)/cgroup | grep io | cut -d: -f3)
验证不能只靠 docker inspect
docker inspect 只显示启动参数，不反映运行时 cgroup 状态。真正确认限制是否加载，必须进容器查原始 cgroup 文件：
- 找路径：先
docker inspect -f '{{.State.Pid}}' CONTAINER，再cat /proc/PID/cgroup定位挂载点 - cgroup v2 下统一路径：
/sys/fs/cgroup/xxx；v1 则分散在/sys/fs/cgroup/cpu/、/memory/等子目录 - 常用检查项：
cpu.max、memory.max、io.max、cpuset.cpus
