vm.dirty_ratio和dirty_background_ratio需按存储介质与业务场景设安全值：SSD建议5/10、HDD建议10/15、低延迟服务建议3/8，且必须满足前者小于后者；优先用bytes参数替代百分比，并配合dirty_expire_centisecs等协同调优。
Linux 系统的磁盘写缓存策略不能靠“一键开启”，它由内核参数、设备层设置和文件系统行为共同决定；盲目调高脏页比例或强制启用硬件写缓存，可能在断电时丢数据，尤其对数据库类服务是高风险操作。
vm.dirty_ratio 和 vm.dirty_background_ratio 怎么设才安全
这两个参数控制内核何时开始异步/同步刷脏页，直接影响写入延迟和数据安全性。它们不是“越大越好”，而是要匹配你的 I/O 模式和内存容量。
-
vm.dirty_background_ratio触发后台回写（不阻塞应用），建议设为 5–15（百分比）：数据库写密集场景用 5，通用服务器用 10，SSD+大内存可用 15 -
vm.dirty_ratio触发同步写（应用会卡住），必须留出缓冲空间，通常设为dirty_background_ratio的 2–3 倍，但绝对不要超过 30 —— 超过后一旦写突发，进程可能被阻塞数秒 - 更稳妥的方式是用字节阈值替代百分比：设置
vm.dirty_background_bytes和vm.dirty_bytes，避免在内存动态变化时行为漂移（例如 128GB 内存服务器可设dirty_background_bytes=268435456即 256MB） - 临时修改：`sudo sysctl -w vm.dirty_background_ratio=8 && sudo sysctl -w vm.dirty_ratio=24`
- 永久生效需写入
/etc/sysctl.conf并运行 `sudo sysctl -p`
/sys/block/*/queue/write_cache 是什么，能随便开吗
这个开关控制的是**块设备驱动层的硬件写缓存**（即 SSD 或硬盘控制器自身的 DRAM 缓存），和内核 page cache 完全不同。它直接绕过内核缓冲，写入速度飙升，但断电即丢数据。
- 查看当前状态：`cat /sys/block/sda/queue/write_cache`（返回
0表示禁用，1表示启用） - 启用它：`echo 1 | sudo tee /sys/block/sda/queue/write_cache`（注意：部分 NVMe 盘不支持该接口）
- 仅当满足以下全部条件时才建议启用：使用带掉电保护（PLP）的商用 SSD、业务允许少量未刷盘数据丢失、已关闭文件系统 barrier（如 ext4 的
barrier=0挂载选项） - 普通消费级 SATA SSD 或无 PLP 的 NVMe 盘，启用后遇到意外断电，
fsync()成功返回的数据仍可能丢失 —— 这违反 POSIX 语义，MySQL/PostgreSQL 默认依赖它保证事务持久性
为什么改了参数但 fio 测试没看到写入提速
常见原因不是参数无效，而是测试方法掩盖了缓存效果，或被其他机制覆盖。
- fio 默认用
--sync=1或--fsync=1会强制刷盘，完全绕过 page cache，此时调dirty_*参数毫无意义 - 测试前没清空缓存：运行 `sync && echo 3 | sudo tee /proc/sys/vm/drop_caches`，否则旧缓存干扰结果
- 文件系统挂载用了
sync选项（如 NFS 或某些容器存储驱动），所有写都直通磁盘 - 应用自己用了
O_DIRECT或O_SYNC标志，跳过了 page cache 层 - SSD 固件内部有写缓存，但被厂商锁死（如部分 Intel 5xx 系列），
/sys/block/*/queue/write_cache显示0且无法写入
真正关键的点是：写缓存策略不是独立开关，它嵌在 page cache → block layer → 设备固件三层中。调参前必须明确你要优化哪一层、能承担什么数据风险，而不是只看 iostat 里的 w_await 下降了多少。
