数据库容器 IO 性能问题通常不在容器内部解决，而是需要调整宿主机的 IO 调度策略和数据卷挂载选项，因为容器共享宿主机的内核块设备层。
先说结论：优先在宿主机层面调整 IO 调度器并使用 noatime 挂载选项，容器内调整通常无效且存在安全风险。
- 先定位：确认瓶颈是磁盘 IO 等待还是容器存储驱动开销。
- 先做：在宿主机修改调度策略，挂载数据卷时添加 noatime 选项。
- 再验证：通过 iostat 观察 await 指标变化，结合数据库慢查询日志确认。
命令速用版
# 查看宿主机当前 IO 调度策略（假设磁盘为 sda）
cat /sys/block/sda/queue/scheduler# 临时修改宿主机调度策略（例如改为 none 或 mq-deadline）
echo none > /sys/block/sda/queue/scheduler# 获取磁盘 UUID（用于 fstab 配置）
blkid /dev/sdb1# 查看当前挂载选项
mount | grep docker为什么会这样
Docker 容器并不是完全独立的虚拟机，它们共享宿主机的 Linux 内核。这意味着容器内的进程发出的 IO 请求，最终是由宿主机的内核块设备层处理的。如果在容器内部尝试修改 IO 调度策略（如修改/sys/block 下的参数），往往因为没有权限或者操作的是虚拟设备而无效，甚至可能误导排查方向。
此外，文件系统每次读取文件时默认会更新访问_time（atime），这对于数据库这种频繁读取的场景会产生大量不必要的写操作。通过在挂载时禁用 atime 更新，可以减少元数据写入，但具体的性能提升幅度取决于 workload 类型，公开资料中没有看到可靠的量化数据，通常建议作为标准优化手段。
分步处理
1. 确认宿主机磁盘类型与调度器
不同的存储介质适合不同的调度策略。机械硬盘（HDD）通常需要调度器来优化寻道，而固态硬盘（SSD）或 NVMe 磁盘在现代内核中通常建议使用 none 或 mq-deadline。
# 查看磁盘类型提示（部分系统支持）
lsblk -d -o name,rota
# rota=1 通常为 HDD，rota=0 通常为 SSD2. 调整宿主机 IO 调度策略
在宿主机上执行修改。注意，这种修改重启后可能失效，建议写入启动脚本或使用 udev 规则持久化。
# 查看可用的调度器
cat /sys/block/sda/queue/scheduler
# 输出示例：[none] mq-deadline kyber bfq# 切换调度器（以 none 为例，适合 SSD）
echo none > /sys/block/sda/queue/scheduler# 创建 udev 规则持久化配置（重启生效）
echo 'ACTION=="add|change", KERNEL=="sda", ATTR{queue/scheduler}="none"' > /etc/udev/rules.d/60-scheduler.rules3. 优化数据卷挂载选项
数据库数据目录建议使用独立卷或绑定挂载，并添加 noatime 选项。如果是 Docker volume，需要在 daemon.json 或创建卷时配置，但更常见的是直接绑定挂载宿主机已优化挂载的目录。
警告：修改 fstab 前务必备份，配置错误可能导致系统无法启动。执行 remount 前请停止相关容器，避免 IO 错误。
# 备份 fstab 配置文件
cp /etc/fstab /etc/fstab.bak# 获取磁盘 UUID
blkid /dev/sdb1# 修改宿主机/etc/fstab，为数据盘添加 noatime（使用 UUID 替换设备名）
# UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /var/lib/docker/volumes ext4 defaults,noatime 0 2# 停止使用相关目录的容器
docker stop db_container# 重新挂载生效
mount -o remount /var/lib/docker/volumes# 启动容器
docker start db_container4. 检查 Docker 存储驱动
确保使用 overlay2 等成熟驱动。避免在生产环境数据库容器中使用默认的空存储驱动配置，建议将数据库数据目录直接绑定挂载到宿主机高性能磁盘路径，绕过存储驱动的文件层开销。
# 查看存储驱动
docker info | grep "Storage Driver"怎么验证是否生效
调整后不要立即断言性能提升，需观察系统指标。
1. 观察 IO 等待
使用 iostat 查看磁盘利用率和等待时间。
iostat -x 1 10关注await（平均等待时间）和%util（利用率）。如果 await 显著下降且数据库响应变快，说明调整有效。如果%util 持续 100% 且 await 高，说明磁盘本身已达瓶颈，调整调度器帮助有限。
2. 检查数据库日志
查看数据库的慢查询日志（Slow Query Log），确认 IO 相关的等待事件是否减少。例如 MySQL 的ib_log_file写入等待或 PostgreSQL 的log_min_duration_statement。
3. 确认挂载选项
在容器内或宿主机检查挂载参数是否包含 noatime。
mount | grep 数据目录路径常见坑
1. 容器内修改无效
不要在 Dockerfile 或容器启动命令中尝试修改/sys/block 下的调度参数，这通常权限不足且作用于宿主机设备，容器内操作无意义。
2. 数据安全风险
不要为了性能将文件系统挂载选项改为data=writeback。虽然这可能提升写入性能，但在断电或崩溃时会导致严重的数据损坏。数据库本身有 WAL 机制，但文件系统层面的写回策略需保持保守（如 ordered 或默认）。
3. fstab 配置风险
直接编辑/etc/fstab 若配置错误（如 UUID 错误、格式错误）可能导致系统无法启动。务必先备份，并使用 UUID 而非设备名（/dev/sdX）以防磁盘顺序变化。
4. 业务中断风险
对正在运行的数据目录执行 remount 可能导致容器 IO 错误或业务中断。生产环境请在维护窗口操作，并先停止相关容器。修改 IO 调度器无需重启 Docker 服务，重启会导致所有容器短暂不可用。
5. NVMe 磁盘过度优化
现代 NVMe 磁盘自带强大的控制器调度，内核调度器设为 none 通常即可。强行使用复杂的调度算法（如 bfq）反而可能增加 CPU 开销且无 IO 收益。
参考来源
- Linux Kernel Documentation, Block I/O Scheduling, https://www.kernel.org/doc/html/latest/block/index.html
- Docker Official Documentation, Storage drivers, https://docs.docker.com/storage/storagedriver/
- MySQL Official Documentation, Optimizing Storage Engine Performance, https://dev.mysql.com/doc/refman/8.0/en/optimizing-storage-engine.html
原文链接：https://www.zjcp.cc/ask/11073.html