docker compose 不支持 iops 限制，因其资源限制仅覆盖 cpu、内存等通用 cgroup 控制器，未暴露 blkio（v1）或 io（v2）底层控制器；iops 参数如 --device-read-iops 仅可通过 docker run 或 api 设置。
在 docker-compose.yml 中无法直接配置磁盘 IOPS 上限，因为 Docker Compose 本身不支持 blkio 类型的资源限制（如 --device-read-iops 或 --device-write-iops），这些参数只能通过 docker run 命令行或底层 docker engine 的 API 设置。
为什么 docker-compose.yml 不支持 IOPS 限制
Docker Compose 的资源限制（deploy.resources.limits）目前仅支持 CPU、内存等 cgroup v1/v2 的通用控制器，而块设备 I/O 限速（blkio）属于更底层的 cgroup v1 控制器（cgroup v2 中已整合为 io 控制器），但 Compose 的 YAML schema 尚未暴露该能力。即使你使用 docker stack deploy（基于 Swarm），也仅支持 resources.reservations/limits 中的 cpus 和 memory，不包括 I/O。
可行的替代方案
若需对容器强制实施磁盘读写 IOPS 限制，可采用以下方式：
-
改用
docker run手动启动：在部署关键服务时绕过 Compose，直接使用支持 blkio 的命令，例如：docker run --device-read-iops /dev/sda:1000 --device-write-iops /dev/sda:500 nginx -
在宿主机启用 cgroup v2 + 使用
io.max（推荐）：确保内核 ≥5.0、Docker Engine ≥20.10 且启用 cgroup v2（默认 Ubuntu 22.04+/CentOS 8+ 已启用）。然后通过docker run --io-max-bandwidth或--io-max-iops（实验性支持，需 Docker 24.0+）设置，但注意：Compose 仍不解析这些字段。 -
用 systemd + slice 间接控制（适用于长期服务）：将容器进程归入特定 systemd slice（如
io-heavy.slice），再通过/etc/systemd/system/io-heavy.slice.d/10-io.conf配置：[Slice]<br> IOAccounting=true<br> IOWeight=10
然后用docker run --systemd=true --cgroup-parent=io-heavy.slice ...启动（需 Docker 启用 systemd cgroup driver）。
Compose 中能做的“软防护”措施
虽然不能设硬 IOPS 上限，但可通过以下方式降低邻居干扰风险：
-
绑定专用物理设备：用
volumes挂载宿主机独立 SSD 分区（如/mnt/fast-ssd:/data），避免多个容器争抢同一块盘的队列； -
限制容器写频次与缓存行为：在应用层配置（如数据库的
sync_binlog=0、innodb_flush_log_at_trx_commit=2），配合 host 挂载tmpfs缓冲临时 I/O； -
启用
read_only: true+tmpfs：对无状态容器禁用写入，所有临时文件走内存盘，彻底规避磁盘争抢。
不复杂但容易忽略：IOPS 干扰本质是共享块设备队列导致的延迟毛刺，真正有效的隔离往往不在容器编排层，而在存储拓扑设计（如 NVMe 直通、本地 PV 分配）和内核 I/O 调度策略（如 none 或 kyber）上。
