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 设置不当导致的写放大里——这三个参数只是表层杠杆，撬不动底层设计缺陷。
