docker compose 不支持直接配置 iops 上限，因 v3.x 未定义对应字段；可通过 swarm 的 devices 带宽限制（非 iops）、docker run 透传 --device-read-iops/--device-write-iops、cgroup v2 手动设 io.max、或 lvm-thin + dm-iotune 等方式间接实现。
Docker Compose 本身不直接支持为服务配置磁盘 IOPS 上限（如 --device-read-iops / --device-write-iops），这些是 Docker CLI 的 run 或 create 命令原生支持的运行时参数，而 docker-compose.yml v3.x（包括 v3.8、v3.9）未定义对应字段。但可通过以下方式间接实现：
使用 deploy.resources.limits 在 Swarm 模式下限制 I/O（仅限 Swarm）
如果你在 Docker Swarm 集群中部署（即用 docker stack deploy），可在 deploy.resources.limits 下配置 devices 限制 —— 但注意：Swarm 目前仅支持设备带宽（bytes/sec）限制，不支持 IOPS（IO per second）限制。
示例（限制块设备读写带宽，非 IOPS）：
services:
db:
image: postgres:15
deploy:
resources:
limits:
devices:
- driver: "linux"
count: 1
capabilities: ["io"]
# ⚠️ 注意：以下字段是带宽（B/s），不是 IOPS
options:
io.max: "sda 10485760" # 10MB/s 读写总上限（需内核支持 blkio cgroup v1）
⚠️ 实际效果受限于：cgroup v1 + blkio 子系统启用、宿主机内核版本（≥4.18 推荐）、Docker 版本（≥20.10）、且仅对物理设备（如 sda）有效，对 overlay2/volume 不生效。
通过 runtime 配置传递原始 --device-* 参数（推荐方案）
最可靠的方式是让 Compose 启动容器时“透传” Docker CLI 支持的 IOPS 参数。这需要：
- 使用 Compose v2.20+（2023 年后版本）
- 启用实验性字段
runtime或extra_hosts等不被 schema 校验的字段（部分版本支持） - 更通用且稳定的做法：改用
docker run命令 +docker-compose config导出配置
✅ 推荐操作流程（无需修改 yml）：
- 保持
docker-compose.yml不变（专注服务定义） - 用
docker-compose config --services确认服务名 - 手动启动并添加 IOPS 限制（适合测试/CI/安全加固场景）：
docker run \ --device-read-iops /dev/sdb:500 \ --device-write-iops /dev/sdb:300 \ --name mydb \ -v /data/db:/var/lib/postgresql/data \ -e POSTGRES_PASSWORD=secret \ postgres:15
这样可精确限制某块物理盘（如 /dev/sdb）的读 500 IOPS、写 300 IOPS，有效隔离邻居干扰。
用 volume driver 或 host-path + udev/cgroup 手动管控（生产级兜底）
若必须用 Compose 启动且需强 IOPS 隔离，建议：
-
为关键服务分配独立物理磁盘或 NVMe namespace（如
/dev/nvme0n1p1），再用--device-read-iops绑定 - 在宿主机上用
udev固定设备名，避免sda/sdb变化导致策略失效 - 配合
cgroup v2 + io.max文件手动设置（路径如/sys/fs/cgroup/myapp/io.max），内容形如：8:16 rbps=10485760 wbps=5242880 riops=500 wiops=250（主次设备号+IOPS/带宽混合策略）
该方式绕过 Docker 层，由内核强制执行，隔离强度最高，适合金融、SaaS 多租户等强 SLA 场景。
替代思路：用轻量存储层做 QoS（如 LVM-thin + dm-iotune）
如果底层是 LVM，可创建 thin pool 并用 dm-iotune 或 ionice（虽非硬限，但可降低干扰概率）：
- 对 volume 使用
ionice -c2 -n7启动进程（仅影响调度优先级，不阻断突发 IO） - 结合
blkio.weight（cgroup v1）或io.weight（cgroup v2）做相对权重控制，适用于同盘多服务场景 - 例如在容器内执行：
echo "8:16 100" > /sys/fs/cgroup/io.weight（需挂载 cgroup2）
这种方式不能设绝对 IOPS 上限，但能显著降低高 IO 服务对邻居的“毛刺”影响，实施成本低、兼容性好。
不复杂但容易忽略：IOPS 限制只对直接访问的块设备生效，对 Docker volume（尤其是 local driver 背后的 overlay2）或网络存储（NFS、Ceph RBD）无效。真正防邻居干扰，要从物理设备划分 + 内核级限流双管齐下。
