vm.dirty_background_ratio=5会导致后台回写过早触发，易引发iowait升高和延迟抖动；应与vm.dirty_ratio保持至少5%差值，并配合调大vm.dirty_expire_centisecs以合并刷盘、降低I/O频次。
vm.dirty_background_ratio=5 会导致后台回写太激进
这个值设成 5 意味着只要脏页占系统内存的 5%，内核就立刻启动后台回写线程（pdflush 或 writeback），对 I/O 压力敏感的场景（比如数据库、高吞吐日志写入）容易引发持续的小量磁盘刷写，反而拖慢整体响应。
常见现象包括：iowait 升高、dd 或 fsync 延迟抖动、top 中 kswapd0 和 ksmd 争抢 CPU。
- 默认值是
10，对大多数通用服务器更稳妥 -
vm.dirty_background_ratio和vm.dirty_ratio应保持至少 5 个百分点差值，否则后台线程刚启就撞上限，陷入“启-压-堵-再启”循环 - 若必须压低该值（如内存极小的嵌入设备），务必同步调大
vm.dirty_expire_centisecs
vm.dirty_expire_centisecs 延长能缓解短时脏页洪峰
这个参数控制脏页在内存中“最长可活多久”（单位是厘秒，即 1/100 秒）。默认 3000（30 秒），设为 6000（60 秒）或 12000（120 秒）后，内核会更倾向于把多次小写合并成一次批量刷盘，降低 I/O 频次。
但注意：延长不等于“不刷”，只是推迟决策点；最终是否刷、刷多少，仍受 vm.dirty_background_ratio 和 vm.dirty_ratio 约束。
- SSD 场景可放心设到
12000，磨损影响小，吞吐收益明显 - HDD 场景建议不超过
6000，避免单次刷盘太久阻塞后续写入 - 若应用本身频繁调用
fsync()或sync_file_range()，该参数影响会被部分绕过
组合调优时必须检查 vm.dirty_ratio 上限
vm.dirty_background_ratio=5 已经很保守，如果 vm.dirty_ratio 还卡在默认 20，那留给后台回写的缓冲空间只有 15 个百分点——一旦脏页增长稍快（例如突发日志写入），就会很快触达 vm.dirty_ratio，触发同步阻塞式刷盘（进程卡在 write() 直到脏页回落），比后台刷更伤性能。
- 建议将
vm.dirty_ratio设为15或10，与vm.dirty_background_ratio=5形成安全梯度 - 修改后用
echo $(( $(grep -i "memtotal" /proc/meminfo | awk '{print $2}') * 5 / 100 ))算出对应脏页字节数，确认是否符合业务写入节奏 - 不要只看百分比：在 128GB 内存机器上
5%是 6.4GB 脏页，足够撑住多数 OLTP 场景；但在 4GB 小内存设备上仅 200MB，可能需进一步调低比例或改用vm.dirty_background_bytes
验证回写行为是否真的变“懒”了
光改参数没用，得看 writeback 实际节奏。最直接的方式是监控 /proc/vmstat 中的计数器变化：
- 关注
nr_dirty（当前脏页数）、nr_writeback（正在回写页数）、pgpgout（每秒页写出量） - 用
watch -n 1 'grep -E "^(nr_dirty|nr_writeback|pgpgout)" /proc/vmstat'对比调参前后波动幅度 - 若
nr_writeback从“始终有几十页在写”变成“间歇性跳升到几百页再归零”，说明延长vm.dirty_expire_centisecs起效了 - 注意避开 swap 活跃期干扰：
swpd非零时pdflush行为会被调度逻辑干扰，测试前先swapoff -a
真正难的是平衡：脏页留太久，OOM 风险上升；刷太勤，I/O 成瓶颈。没有全局最优解，只有贴合你 workload 的那个临界点。
