SQL PostgreSQL 的 wal_buffers / wal_writer_delay / commit_delay 的 WAL 写性能调优

wal_buffers过小会导致wal写入卡顿，表现为checkpoints_timed飙升和会话等待“waiting for wal to be written”；建议oltp设64–128mb、高写入设256mb（≤shared_buffers/8），需重启生效。

wal_buffers 设得太小会卡住写入

postgresql 的 wal_buffers 是 WAL 日志的内存缓冲区，它不共享于 shared_buffers，而是独立分配。默认值通常是 16MB（或 shared_buffers / 32，取较大者），但如果你的事务日志量大、并发高，这个值很容易成为瓶颈——表现是 pg_stat_bgwriter 中 checkpoints_timed 飙升，同时 pg_stat_activity 里大量会话卡在 waiting for WAL to be written 状态。

实操建议：

• 观察 pg_stat_bgwriter 的 buffers_written 和 maxwritten_clean：如果后者频繁触发（说明后台写进程被逼着刷太多页），说明 WAL 缓冲压力大，wal_buffers 可能偏小
• 对 OLTP 场景，建议设为 64MB～128MB；对高吞吐写入（如批量导入、逻辑复制下游），可到 256MB，但不要超过 shared_buffers 的 1/8，否则挤占查询内存
• 该参数必须重启生效，不能 ALTER SYSTEM SET 后 select pg_reload_conf()
• 注意：增大后若 WAL 写入延迟没改善，问题大概率不在这里，别盲目调大

wal_writer_delay 控制 WAL 刷盘节奏

wal_writer_delay 决定 WAL writer 进程每轮检查是否需要刷盘的间隔，默认 200ms。它不是“每 200ms 必然刷一次”，而是“每 200ms 醒来，看有没有积压 WAL 要落盘”。所以它影响的是 WAL 持久化的及时性与合并效率之间的平衡。

实操建议：

• 降低到 10ms～50ms 可减少单次提交的持久化延迟（对 synchronous_commit = on 场景明显），但会增加 fsync 频率，可能抬高 I/O 压力
• 提高到 500ms 或更高，适合磁盘慢、允许少量 WAL 积压的场景（比如备库同步压力大时临时缓解），但会拉长最长提交延迟，极端下可能让事务等满 wal_writer_delay + wal_writer_timeout
• 它和 wal_writer_timeout（默认 5s）配合工作：如果 WAL writer 连续超时未刷，会强制唤醒并刷出所有积压 —— 所以调高 wal_writer_delay 时，务必确认 wal_writer_timeout 是否合理
• 该参数可热更新，但修改后需关注 pg_stat_bgwriter.wal_sync 和 wal_write 的比率变化

commit_delay 在高并发小事务下有用，但有代价

commit_delay 是指事务进入 commit 状态后，不立刻触发 WAL fsync，而是等待最多指定微秒（单位是 µs），看是否有其他事务也正要提交 —— 如果有，就打包一起刷盘。它只对 synchronous_commit = on 且使用本地 WAL buffer 的事务生效。

实操建议：

• 仅在大量短事务（如单行 INSERT/UPDATE）、且磁盘 fsync 很慢（比如 HDD 或某些云盘）时考虑启用；典型值是 10000（10ms）到 100000（100ms）
• 开启后必须配 commit_siblings > 1（默认 5），否则没人等，delay 就白设了；它只在当前时刻活跃事务数 ≥ commit_siblings 时才触发延迟行为
• 副作用明显：单个事务的最坏延迟 = commit_delay + fsync_time，可能从毫秒级变成百毫秒级，不适合低延迟敏感业务
• SSD 或现代云盘（如 AWS gp3、azure P30）通常 fsync 很快，commit_delay 收益极小，反而引入不可控延迟，不建议开

三个参数之间的真实依赖关系

这三个参数不是孤立调节的：它们共同作用于 WAL 生命周期的三个阶段——缓存（wal_buffers）、后台调度（wal_writer_delay）、提交协同（commit_delay）。调错一个，其他参数的优化效果会被掩盖。

实操建议：

• 先确认你的瓶颈在哪：用 pg_stat_bgwriter 看 wal_sync 和 wal_write 比率是否接近 1（说明 WAL writer 跟得上）；再用 pg_stat_database 看 xact_commit 和 xact_rollback 的速率，判断是否真有高并发小事务
• wal_buffers 不足时，wal_writer_delay 再小也没用——WAL buffer 频繁满，writer 被迫高频刷；反之，buffer 够大但 wal_writer_delay 过长，WAL 就堆在内存里不动
• commit_delay 是最后才动的开关，且只在明确观测到大量 WALWriteLock 等待或 pg_stat_activity.state = 'active' 但 wait_event_type = 'Lock' 且 wait_event = 'WALWriteLock' 时才值得尝试
• 所有调整必须结合 pg_stat_bgwriter、pg_stat_database 和系统 I/O 等待（如 iostat -x 1）交叉验证，单看某一个指标容易误判

真正卡 WAL 写性能的地方，往往藏在 WAL segment 切换频率、归档命令阻塞、或者 checkpoint_timeout / checkpoint_completion_target 设置不当导致的写放大里——这三个参数只是表层杠杆，撬不动底层设计缺陷。