SQL checkpoint_completion_target 0.9 的检查点平滑分布实践

设为0.9不一定让写入更平滑，它仅控制脏页刷盘在checkpoint_timeout时间内的占比；需i/o能力、脏页生成速率稳定，否则仍会触发紧急检查点。

checkpoint_completion_target 设为 0.9 真的能让写入更平滑吗？

不一定。它只控制「检查点实际持续时间」占「目标检查点间隔」的比例，不是写入负载的调节器。设成 0.9 意味着 postgresql 会尽量把脏页刷盘动作摊开在 90% 的 checkpoint_timeout 时间内完成——前提是系统 I/O 能跟上、脏页生成速率稳定、且没有突发写入高峰。

• 如果 checkpoint_timeout = 300（5 分钟），checkpoint_completion_target = 0.9 就会尝试把刷盘任务控制在 270 秒内做完，留 30 秒空档
• 但若这期间有大量 UPDATE 或 copy，脏页生成速度远超刷盘能力，系统仍会触发「紧急检查点」或出现 too many checkpoints 日志
• SSD 上效果通常比 HDD 明显，因为随机写延迟低，能更好响应调度节奏

为什么调高到 0.9 反而导致 wal_keep_size 不够？

延长刷盘窗口本身不直接增加 WAL 保留量，但间接放大了 WAL 滞后风险：当检查点拉得长、刷盘慢，主库可能提前覆盖掉备库还没来得及读取的 WAL 文件，尤其在流复制场景下容易触发 could not receive data from WAL stream: Error: requested WAL segment has already been removed。

• wal_keep_size 是静态水位线，不随 checkpoint_completion_target 自动调整
• 设为 0.9 后，单次检查点周期内产生的 WAL 量未必变多，但 WAL 生效与回收的时间差被拉长，需预留更多缓冲空间
• 建议同步调高 wal_keep_size 至至少 2× 原值（例如从 128MB 改为 256MB），并观察 pg_stat_replication 中的 replay_lag

和 synchronous_commit = off 一起用会放大什么风险？

会显著提高崩溃后数据丢失概率，且这种丢失是「静默」的——事务返回成功，但对应 WAL 可能根本没落盘，连检查点都来不及覆盖。

• checkpoint_completion_target = 0.9 关注的是「已提交事务的 WAL 如何被刷盘」，而 synchronous_commit = off 允许客户端在 WAL 还在内核 buffer 里时就收到成功响应
• 两者叠加时，一次批量写入可能产生大量脏页 + 大量未刷 WAL；检查点虽努力平滑刷脏页，但 WAL 本身已处于高危状态
• 典型错误现象：服务重启后发现最近几秒的 INSERT 全部消失，且日志里查不到对应 WAL 归档失败记录

如何验证 0.9 是否真起作用？

别只看配置是否生效，重点查 pg_stat_bgwriter 里的运行时指标，它们反映真实调度效果。

• 关注 checkpoints_timed 和 checkpoints_req 的比值：若后者占比持续 > 10%，说明强制检查点太多，0.9 的平滑意图已被频繁写压破坏
• 计算 checkpoint_write_time / (checkpoint_sync_time + checkpoint_write_time)，理想值应接近 0.9；明显偏低（如 0.3）说明刷盘太快，可能是 bgwriter_lru_maxpages 太小或 I/O 能力过剩
• 用 select now() - pg_postmaster_start_time(); 对照 pg_stat_bgwriter.checkpoint_time，确认检查点是否真的按预期间隔分布，而非扎堆发生

真正难调的从来不是参数值本身，而是脏页生成节奏和底层存储响应之间的咬合精度——磁盘延迟能抖动 20ms，你的 0.9 就可能变成 0.6 或 1.0。