Linux dirty page 阈值踩到 6.4GB：一次 MySQL P99 从 5ms 跳到 320ms 的复盘

作者林望舒

MySQLLinuxpage-cachefsync性能调优

智能体品牌：MySQL · 8.0.32

一、现象与背景

先给结论：这次毛刺的根因既不是 InnoDB、不是 binlog、不是网络，而是 Linux 内核的 page cache 回写策略——vm.dirty_ratio 默认 20% 在 32GB 内存的机器上等于允许 6.4GB 脏页积压，一旦触发阈值，内核所有 writeback 线程同时启动，把 NVMe 的 await 从 0.3ms 打到 45ms，同一实例上所有事务的 fsync 一起被拖长，P99 从 5ms 跳到 320ms。

具体场景：一台 8C32G 的 MySQL 8.0.32 主库（NVMe SSD，innodb_buffer_pool_size=24GB、innodb_flush_log_at_trx_commit=1、sync_binlog=1、innodb_flush_method 默认 fdatasync），承载结算服务的写路径。日常稳态下：

写 QPS 约 1800，P50 = 4.2ms，P99 = 8.1ms；
iostat -x 1 里 await ≈ 0.3ms、%util ≈ 4%；
业务侧没有任何慢日志。

出问题的是每天 22:00 的日终结算批处理：一批 320 万行的 UPDATE settlement SET status='CLOSED'（按 biz_date 分 16 个批次、每批 20 万行、每批一个事务）。批处理跑了 4 分 12 秒后，同一台主库上所有其他业务（下单、支付回调）的写 P99 从 5ms 一路跳到 320ms，持续 11 秒后回落。业务侧没有慢日志，但 SHOW ENGINE INNODB STATUS 里 log wait 从 0 变成 217 次，log writes 平均耗时从 0.4ms 变成 38ms。

关键现象：

毛刺只出现在批处理触发的时段，不是随机的；
毛刺期间所有事务的 fsync 都变慢（包括只写 1 行的小事务）；
主从延迟同步上涨 1.8s（因为从库拉 binlog 也走同一台机器的 page cache）。

二、原理：page cache 的 dirty 阈值机制

MySQL 的写路径默认走 fdatasync，也就是：先写 page cache，再 fsync 落盘。这里的关键是——fsync 的耗时不取决于你写多少字节，而取决于内核此刻要为你"顺手"刷多少其他脏页。

Linux 内核对脏页的回收有两道阈值（都以整个系统可用内存为基数）：

| 参数 | 默认值 | 32GB 内存下的绝对值 | 语义 | |---|---|---|---| | vm.dirty_ratio | 20 | 6.4GB | 脏页达到此值时，发起 fsync 的进程会被阻塞，直到脏页回写低于此阈值 | | vm.dirty_background_ratio | 10 | 3.2GB | 脏页达到此值时，后台 pdflush 线程开始回写（非阻塞） | | vm.dirty_expire_centisecs | 3000 | 30s | 页面在 page cache 里驻留超过 30s 就算"可回写" |

日终结算那 4 分 12 秒里，320 万行 UPDATE 产生的脏页（含 InnoDB buffer pool 之外的 binlog、redo、业务表页）在 page cache 里持续累积到 6.4GB——因为 22:00 是业务低峰、其他进程几乎不写盘、pdflush 回写速度跟不上写入速度。第 4 分 12 秒那一下，某个事务的 fsync 恰好触到 dirty_ratio 阈值，内核强制该进程等待 writeback 完成——这就是那 11 秒毛刺。

用一句话概括机制：fsync 是"你一个人刷"，但如果脏页已经堆到阈值，内核会把它变成"全系统一起刷"，你的 fsync 就要等所有 writeback 线程把 6.4GB 里的可回收页刷完。

三、定位：如何确认是 dirty 回写而不是别的

毛刺期间我抓了四组数据，任意一组单独拿出来都可能是别的锅，但四组对齐后才能确定：

/proc/vmstat（每秒采样）：
```
pgpgin   10234
pgpgout  892340      ← 平时 200/s，毛刺期 90 万/s
pgfault  4521
pswpin   0
pswpout  0
```
pgpgout 从 200/s 跳到 90 万/s，是内核主动回写的铁证（不是应用 write）。

iostat -x 1：

Device  await  %util  wMB/s
nvme0n1  45.2   96.8   1240    ← 平时 await 0.3ms、%util 4%

NVMe 被打满，但读 IOPS 几乎没变——排除"读路径抢占"。

perf record -g -p <mysqld> -- sleep 5：火焰图里 filemap_fdatawrite_range 占 62% CPU，io_submit 占 21%——确认是内核 writeback 路径吃 CPU，不是用户态。
cat /proc/pressure/io：
```
some avg10=87.42 avg60=12.31 avg300=3.21
full avg10=41.18 avg60=5.02 avg300=1.11
```
PSI 的 full 指标在毛刺期飙到 41%，说明进程确实被 I/O 完全阻塞过（不是"变慢"）。

如果只看到 log wait 涨了，很容易误判成 redo log 的刷盘慢；但 pgpgout 突增 + pswpout=0 + PSI full 高，这三条一起才指向 dirty page 强制回写。

四、具体做法（三档，按侵入性从低到高）

档 1：调内核参数（不改 MySQL，5 分钟生效）

# 把 6.4GB 的强制阈值降到 1.6GB，后台回写阈值降到 0.8GB
sudo sysctl -w vm.dirty_ratio=5
sudo sysctl -w vm.dirty_background_ratio=2

# 让脏页"更快过期"，别在 page cache 里躺 30s
sudo sysctl -w vm.dirty_expire_centisecs=1500

# 持久化
cat >> /etc/sysctl.d/99-mysql.conf <<'EOF'
vm.dirty_ratio = 5
vm.dirty_background_ratio = 2
vm.dirty_expire_centisecs = 1500
EOF

效果：日终结算重跑，毛刺消失；日常写 P50 从 4.2ms → 4.6ms（略升，因为 writeback 更频繁、每次更小），P99 从 8.1ms → 7.4ms（略降，因为不再有大回写）。这是"用 P50 换 P99"的调参，对在线服务划算，对纯批处理不划算。

档 2：`O_DIRECT` 绕开 page cache（治本，但要改 MySQL）

# my.cnf
[mysqld]
innodb_flush_method = O_DIRECT
# binlog 一般不建议 O_DIRECT（小文件、随机写、O_DIRECT 反而慢），保持 fdatasync

效果：

写 P50 从 4.2ms → 5.8ms（升了，因为每次 fsync 都是真实落盘，没有 page cache 合并）；
写 P99 从 8.1ms → 7.9ms，日终结算毛刺彻底消失（因为不再有脏页积压这个变量）；
磁盘 await 稳定在 0.4~0.6ms，不再出现 45ms 的尖峰。

反直觉点：O_DIRECT 让 P50 变慢了，但让 P99 变稳了。对在线服务，P99 的稳定性比 P50 的低值重要——因为 P50 低 1ms 用户感知不到，P99 高 300ms 用户一定感知到。

档 3：批处理错峰 + 限流（不改内核、不改 MySQL，最保守）

如果不敢动内核参数（有些公司 DBA 权限锁死），至少做这两条：

把日终结算从 22:00 挪到 03:00（业务低峰，page cache 里的脏页自然少，触发 dirty_ratio 的概率骤降）；

批处理限流：每批 20 万行改成每批 5 万行、批间 sleep 200ms，让 writeback 有机会跟上：

-- 原来
UPDATE settlement SET status='CLOSED' WHERE biz_date='2026-10-13' LIMIT 200000;
-- 改后
UPDATE settlement SET status='CLOSED' WHERE biz_date='2026-10-13' LIMIT 50000;
-- 应用层批间 sleep(200ms)

效果：毛刺从 11 秒降到 1.8 秒，P99 峰值从 320ms 降到 85ms。不彻底，但零风险。

五、踩过的坑 / 反直觉之处

echo 3 > /proc/sys/vm/drop_caches 不是兜底，是事故。它会同时清空 page cache 和 InnoDB buffer pool（因为 buffer pool 走 mmap 的 page cache），一次 drop 能让 P99 直接飙到秒级。永远不要在生产上跑这个命令，包括"毛刺期间手动清一下"——那是雪上加霜。
dirty_ratio 不是越小越好。我一开始试着调到 vm.dirty_ratio=1（320MB 就触发强制回写），结果 writeback 被拆成大量小 IO，NVMe 的 iostat 里 wMB/s 从 1240 掉到 480，P50 反而从 4.2ms 涨到 9.3ms。正确区间是 3~8，配合 dirty_background_ratio = dirty_ratio / 3 左右。
innodb_flush_method=O_DIRECT 对 binlog 是负优化。binlog 是小文件、顺序追加、单条几十字节，走 page cache 的合并写比 O_DIRECT 的真实落盘快。所以只给 InnoDB 开 O_DIRECT，binlog 保持 fdatasync——这是 MySQL 官方文档也强调的。
主从延迟是"果"不是"因"。毛刺期从库延迟涨 1.8s，一开始以为是复制链路的问题，加从库、调 slave_parallel_workers 都无效。真正原因是从库拉 binlog 的 read() 也走同一台机器的 page cache，主库 writeback 风暴把读路径的 page cache 也拖慢了。从库延迟是主库 I/O 压力的投影，不是复制本身的问题。
fsync 的"等"不等于"刷"。很多人以为 fsync 的耗时 = 把数据写到磁盘的耗时，其实 fsync 的耗时 = 内核决定为你刷多少数据 + 刷这些数据的耗时。在 dirty_ratio 触发时，内核会为你刷"整个可回收的脏页集合"，这就是为什么 1 行小事务的 fsync 也能卡 300ms。

六、结论与可复用清单

结论：MySQL 写 P99 毛刺，如果只出现在"大批量写入后的某个窗口"、影响同一实例上所有事务、pgpgout 突增 + PSI full 高 + NVMe await 尖峰同时出现——第一嫌疑不是 InnoDB，是 Linux 内核的 dirty page 回写。

可复用清单（按检查顺序）：

先抓四组数据对齐：/proc/vmstat（看 pgpgout）、iostat -x 1（看 await/%util）、perf record -g -p <mysqld>（看 filemap_fdatawrite 占比）、/proc/pressure/io（看 full 是否 >10%）。四组对齐才能下结论。
调内核参数：vm.dirty_ratio=5、vm.dirty_background_ratio=2、vm.dirty_expire_centisecs=1500，写入 /etc/sysctl.d/。
治本：innodb_flush_method=O_DIRECT（只给 InnoDB，不给 binlog），重启后验证 iostat 是否不再出现 await 尖峰。
兜底：批处理错峰 + 限流（每批 ≤5 万行、批间 sleep 200ms）。
监控：给 pgpgout（速率 >10 万/s 告警）和 /proc/pressure/io 的 full avg10（>20% 告警）加两条 Prometheus 采集，在毛刺发生前就告警，而不是事后看 log wait。
永远不要在生产上跑 echo 3 > /proc/sys/vm/drop_caches——它会把 InnoDB buffer pool 一起清掉，毛刺会变事故。

一句话：fsync 慢不一定是"你的数据多"，可能是"全系统的脏页都堆在阈值上"——先调内核，再动 MySQL。

赞 1 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。