docker不支持在docker-compose.yml中直接配置磁盘iops上限，因其deploy.resources.limits仅支持cpu、内存等通用资源，而--device-read-iops等i/o限速参数属运行时选项，依赖cgroup底层控制但未纳入compose声明式模型。
容器内应用无法“直接识别”IOPS限额——Docker本身不向容器进程暴露IO限速策略，它只是通过cgroup blkio子系统在内核层面拦截和节流IO请求。所谓“识别”，实际是指让应用行为符合限制预期、或能在运行时感知到IO受控效果。这需要结合参数配置、挂载方式、验证手段与应用适配四方面协同实现。
明确IOPS限制的生效前提
Docker只支持对宿主机真实块设备（如/dev/nvme0n1、/dev/sdb）设置IOPS限制，且依赖cgroup v1 blkio或cgroup v2 io控制器。关键前提包括：
- 宿主机内核启用CONFIG_BLK_CGROUP（cgroup v1）或CONFIG_CGROUP_IO（cgroup v2）
- 容器启动时使用--device-read-iops或--device-write-iops显式指定设备路径与数值
- 应用IO路径必须最终落到该设备：例如MySQL数据目录挂载在/mnt/ssd，而/mnt/ssd所在文件系统底层是/dev/nvme0n1
- 不能与--device-read-bps对同一设备混用，否则iops参数会被静默丢弃
正确配置IOPS限制参数
使用--device-read-iops和--device-write-iops时需注意格式与约束：
- 设备路径必须是宿主机视角的绝对路径，如--device-read-iops=/dev/nvme0n1:2000，而非容器内看到的/dev/xvda
- IOPS值为正整数，不支持小数；设为0等同于未设置
- 可多次使用参数限制多个设备，例如：--device-read-iops=/dev/nvme0n1:1500 --device-write-iops=/dev/sdb:300
- 若应用只读不写，仅设--device-read-iops即可，写入不限速不影响读限制生效
让应用IO真正命中限速设备
很多容器因存储路径设计不当，导致IO绕过限速设备。实战中必须确保：
- 数据库类应用（如PostgreSQL、Redis）的数据目录使用命名卷或bind mount，挂载点底层对应被限速的块设备
- 避免将数据写入容器可写层（overlay2的upperdir），因其IO经由宿主机根文件系统中转，不受/dev/sda级限速控制
- 检查挂载关系：findmnt -D /var/lib/postgresql/data确认其所在文件系统设备号与限速设备一致
- 对SSD/NVMe设备优先用iops而非bps，更贴合随机小IO场景的实际性能模型
验证限制是否真实生效
不能依赖docker inspect或docker stats——它们不反映底层blkio节流状态。应进入容器验证：
- 查cgroup配置：cat /sys/fs/cgroup/io.max（cgroup v2）或cat /sys/fs/cgroup/blkio/blkio.throttle.read_iops_device（cgroup v1），输出应含设备主次号与IOPS值
- 用fio压测观察瓶颈：fio --name=randread --ioengine=libaio --rw=randread --bs=4k --direct=1 --runtime=60 --time_based --group_reporting
- 宿主机上用iotop -p $(pidof fio)确认进程IO速率稳定在设定IOPS附近，而非持续飙升
- 注意page cache影响：加--direct=1绕过缓存，才能测出真实设备级限速效果
