结论先行：写密集机器（日志采集、ETL、MySQL 主库、Kafka）上那种「每天固定时段、持续 3~10 秒、所有 CPU / 内存 / 网络指标全绿，只有 P99 抖一下」的毛刺，十有八九是内核 page cache 回写（writeback）风暴——
vm.dirty_ratio默认 20% 在 64GB 内存的机器上等于允许 12.8GB 脏页悄悄积压，一旦越线，内核flush线程和应用进程同时抢同一块 NVMe 的带宽，await 从 0.4ms 打到 8~20ms，应用侧表现就是 P99 从 6ms 跳到 400ms+。这篇文章把机制、判定命令、一组能直接抄的 sysctl 参数和 4 个反直觉坑一次讲清。
一、现象：每天 14:20 左右，P99 固定抖 6 次、每次 3~8 秒
先交代规模和数字，方便对号入座。
- 机器：CentOS 7.9（内核 3.10.0-1160，XFS，NVMe 470GB），64GB 内存，16C，跑日志采集 + 一个 ETL 任务（每小时批量写 2~4GB CSV 到
/data/etl）。 - 应用侧：Go 1.21 的 ingestion 服务，平时 P50 = 4ms、P99 = 6ms，QPS 约 800。
- 毛刺形态：每天 14:20 前后固定出现 4~8 次，每次 3~8 秒，P99 打到 380~520ms，P999 直接 1.2s。业务侧 SLA 告警每天被它误报 2~3 条。
- 诡异点：毛刺期间
top里 CPU 才 30%、内存 52%（其中 cache 占 31GB）、iostat的%util峰值只有 62%（NVMe 完全没打满）、网络rx/tx曲线平得可以当直线。所有常规指标都「不算高」，唯独延迟炸了。
一开始我以为是 ETL 任务和应用抢 IO，把 ETL 挪到 03:00 跑，结果 14:20 的毛刺还在——只是幅度小了一半。这说明根因不是「谁在写」，而是「内核什么时候决定把脏页刷下去」。
二、原理：writeback 是「攒够才刷」，攒够了就一起冲
把内核的脏页回写想成一个餐厅后厨：
- 应用
write()一个字节到文件，数据先落进 page cache（内存里），write()立即返回 0，应用觉得「写完了」。 - 这块 page 被标记为 dirty（脏页），内核不会立刻刷盘——刷盘是 IO 密集操作，内核的策略是攒一批再刷，摊薄 IO 成本。
- 「攒多少才刷」由两个阈值控制：
vm.dirty_ratio（默认 20%）：全局脏页占系统内存的百分比。越线 → 应用下一次 write 会被内核同步阻塞（balance_dirty_pages），内核启动flush线程批量回写。vm.dirty_background_ratio（默认 10%）：后台回写启动阈值。越线 → 内核的pdflush/writeback线程开始主动刷，但应用不阻塞。
- 在 64GB 内存的机器上：
dirty_background_ratio= 6.4GB，dirty_ratio= 12.8GB。也就是说，内核默认允许最多 12.8GB 的写数据压在内存里不刷盘——对 470GB 的 NVMe 来说，一次性刷 12.8GB 意味着 12.8GB / 1.2GB/s ≈ 10 秒的满带宽 IO。
这就是毛刺的机制：平时 ETL + ingestion 慢慢写，脏页在 6.4GB 附近徘徊（后台刷得过来），不触发同步阻塞；但 ETL 任务批量写 CSV 的那 30 秒里，脏页增速突然到 ~500MB/s，10 秒就冲破 12.8GB 线——内核启动一次「集中清算」，flush 线程把 12.8GB 在 ~10 秒内挤进 NVMe，应用进程恰好在这 10 秒里发新 write，被内核同步阻塞（balance_dirty_pages 会 sleep），同时 NVMe 带宽被 flush 线程吃走 60%+，应用自己的小 IO 也要排队。应用侧表现就是：write 从 200μs 变成 500ms，P99 从 6ms 跳到 400ms+。
为什么 iostat 的 %util 才 62%：NVMe 是并行多队列设备，%util 对 SSD 的语义和 HDD 完全不同——它表示「有请求在飞的时间占比」，NVMe 512 个队列随便塞几个请求就 100%，但带宽才是真瓶颈。看 iostat -x 的 wMB/s 和 await 才有意义。
三、具体做法：一组能直接抄的 sysctl 参数
1. 确认当前值（大概率是默认）
sysctl vm.dirty_ratio vm.dirty_background_ratio vm.dirty_expire_centisecs vm.dirty_writeback_centisecs
# 典型默认：
# vm.dirty_ratio = 20
# vm.dirty_background_ratio = 10
# vm.dirty_expire_centisecs = 3000 # 30 秒
# vm.dirty_writeback_centisecs = 500 # 5 秒
2. 观察脏页水位（毛刺发生前后各采一次）
# 每 2 秒采一次，看 Dirty 列
grep -E 'Dirty|Writeback' /proc/meminfo
# 或更直观：
watch -n 2 'grep -E "^(Dirty|Writeback)" /proc/meminfo'
# 毛刺期间还会看到：
# Dirty 从 ~300000 kB 涨到 13000000 kB（12.8GB），然后 1 秒内跌回 ~200000 kB
# Writeback 短暂冲到 1~3 GB（说明 flush 线程正在干活）
3. 调参（写密集机器推荐）
# 临时生效（重启失效）
sysctl -w vm.dirty_ratio=5
sysctl -w vm.dirty_background_ratio=2
sysctl -w vm.dirty_expire_centisecs=1500 # 15 秒，让脏页别攒太老
sysctl -w vm.dirty_writeback_centisecs=250 # 2.5 秒，让后台刷更勤
# 持久化到 /etc/sysctl.d/99-dirty-writeback.conf
cat > /etc/sysctl.d/99-dirty-writeback.conf <<'EOF'
vm.dirty_ratio = 5
vm.dirty_background_ratio = 2
vm.dirty_expire_centisecs = 1500
vm.dirty_writeback_centisecs = 250
EOF
sysctl --system
参数含义（大白话版）：
| 参数 | 我设的值 | 效果 |
|---|---|---|
| dirty_ratio=5 | 3.2GB 上限 | 脏页最多攒 3.2GB 就强制同步阻塞，单次 flush 量从 12.8GB 降到 3.2GB，IO 风暴窗口从 ~10s 缩到 ~2.6s |
| dirty_background_ratio=2 | 1.28GB 启动 | 后台刷更勤，不让脏页涨到 3.2GB 才被动刷 |
| dirty_expire_centisecs=1500 | 15s | 脏页最多存活 15 秒（默认 30 秒），让老脏页先被刷掉，避免「一批老脏页同时到期」 |
| dirty_writeback_centisecs=250 | 2.5s | 后台 flush 线程每 2.5 秒醒一次干活（默认 5 秒），把「一次大冲」拆成「多次小刷」 |
4. 验证效果
调参后连续观察 3 天：
# 毛刺期间 await 应从 8~20ms 回到 1~3ms
iostat -x 1 30 | grep -E 'nvme|await'
# 应用侧 P99 应从 400ms+ 回到 8~12ms（比原来 6ms 略高，因为刷盘更频繁了，
# 但单次冲击小得多，这是「用平均换峰值」）
我们实测：P99 从「6ms 基线 + 400ms 毛刺」变成「7.5ms 基线、毛刺峰值 35ms、持续 <500ms」，业务侧 SLA 告警从每天 2~3 条降到 0。代价是 iostat 的 wMB/s 曲线从「平时 200MB/s + 毛刺 1.2GB/s」变成「平时 350MB/s + 毛刺 450MB/s」——平均 IO 带宽升高了，但峰值被削平了。这是 writeback 调参的核心 trade-off：用「更频繁的后台刷」换「更小的同步阻塞窗口」。
5. 容器场景（cgroup v2）
如果应用跑在容器里，/etc/sysctl.d/ 是节点级的，对容器内的 writeback 不直接生效（容器共享宿主的 page cache，但 cgroup 有独立的 memory.high / memory.max）。此时优先调宿主机的 sysctl，因为脏页是全局的、不是按 cgroup 隔离的。如果只想限制某个容器的写带宽，用 io.max 限 IOPS / BPS：
# 给容器 cgroup 限 NVMe 写带宽到 500MB/s
echo "8:0 wbps=524288000" > /sys/fs/cgroup/<pod-cgroup>/io.max
四、踩过的坑 & 反直觉点
dirty_ratio是百分比，不是 MB。 很多人第一反应是「设成 1GB」，但它是占系统内存的百分比——在 64GB 机器上 20% = 12.8GB，在 4GB 机器上 20% = 800MB。同一个默认值，在不同内存规模的机器上行为天差地别。这就是为什么「小内存机器没毛刺、大内存机器天天毛刺」——不是大内存机器写得更多，而是它被允许攒的脏页更多。iostat的%util对 NVMe 是假指标。 我一开始盯着%util才 62% 觉得「磁盘没满、不是 IO 问题」，浪费了 2 小时。NVMe 是多队列设备，%util几乎永远接近 100%（或因为采样窗口问题忽高忽低），真正的瓶颈信号是await（平均 IO 延迟）和wMB/s（写带宽）。dirty_ratio=5不是越小越好。 我试过设成 1%，结果iostat的wMB/s从 350MB/s 掉到 120MB/s，应用 write 延迟从 7.5ms 涨到 18ms——因为内核太频繁地做小批量同步刷盘，IO 效率下降、syscall 开销上升。5% 是「单次 flush 量可控」和「刷盘频率可接受」的折中，经验值在 3%~8% 之间按业务调。- 调完参数要等一个完整毛刺周期才能确认效果。 我调完参数 5 分钟后看
iostat觉得「好像没变」，差点回滚。实际上 writeback 行为是按脏页水位触发的，调参后脏页的稳态水位变了，但要等到下一次 ETL 批量写、脏页重新涨到新阈值、再触发 flush，整个周期约 10 分钟。别在调参后 1 分钟内下结论。 /proc/meminfo的Dirty和Writeback是两个不同东西。Dirty是「在 page cache 里、还没刷盘的字节数」，Writeback是「正在被 flush 线程刷、已经离开 page cache 但还没落盘的字节数」。毛刺期间你会看到Dirty先涨到 12.8GB，然后瞬间跌回 200MB，同时Writeback短暂冲到 1~3GB——这个「Dirty 跳水 + Writeback 尖峰」的组合是 writeback 风暴的指纹，比iostat更直接。
五、结论与可复用清单
一句话：写密集机器上的「周期性 P99 毛刺 + 其他指标全绿」，先查 vm.dirty_ratio，再查 dirty_background_ratio，把两者从默认 20%/10% 降到 5%/2%，配合 dirty_writeback_centisecs 从 500 降到 250，用「更频繁的后台刷」换「更小的同步阻塞窗口」，是性价比最高的一次内核调参。
排查清单（按顺序）：
grep -E 'Dirty|Writeback' /proc/meminfo看毛刺前后Dirty是否跳水、Writeback是否尖峰——这是 writeback 风暴的指纹。sysctl vm.dirty_ratio vm.dirty_background_ratio确认是否还是默认 20%/10%——大内存机器上默认值等于允许 12.8GB 脏页积压。iostat -x 1看await和wMB/s，别信%util。- 调参 → 等一个完整毛刺周期 → 验证 P99 和
await是否回到基线。 - 容器场景：调宿主机 sysctl（脏页是全局的），必要时用
io.max限容器写带宽。
参数速查：
| 场景 | dirty_ratio | dirty_background_ratio | dirty_writeback_centisecs | 备注 | |---|---|---|---|---| | 写密集（日志/ETL/DB） | 5 | 2 | 250 | 本文推荐 | | 读为主（缓存/搜索） | 20（默认） | 10（默认） | 500（默认） | 不用调 | | 混合（一般业务） | 10 | 5 | 350 | 折中 | | 内存 < 8GB | 10 | 5 | 350 | 绝对值已经很小，调太低反而伤 |
参考：@林望舒 的 Linux dirty page 阈值踩到 6.4GB：一次 MySQL P99 从 5ms 跳到 320ms 的复盘 从 MySQL 视角讲过同一类问题；@林砚舟 的 一条 log.info 把 P99 从 30ms 拖到 2.3 秒 讲的是应用层日志刷盘，和内核 writeback 是上下游关系——应用层 AsyncAppender 调的是「应用多久 flush 一次到 fd」，内核 writeback 调的是「fd 里的数据多久 flush 到盘」，两层都要看。