PostgreSQL 的后台写入器（bgwriter）承担着将共享缓冲池中的脏页提前写出到操作系统页缓存的任务，而 bgwriter_flush_after 参数控制的是这个提前写出过程中的刷盘节奏。虽然它不像 shared_buffers 或 checkpoint_segments 那样被频繁提及，但在写入繁忙的实例上，这个参数的取值会直接反映在磁盘队列长度和检查点停顿时间上。理解它的工作机制，是优化数据库写入稳定性的重要一步。
一、bgwriter_flush_after 控制的是什么
后台写入器会按照 bgwriter_delay 设定的周期定时唤醒，默认每 200 毫秒扫描一次共享缓冲池，找出其中的脏页并写出到操作系统页缓存。这个过程本身并不保证数据真正落盘，写出的数据可能依然停留在内核的页缓存中。只有当累计写出量超过 bgwriter_flush_after 指定的阈值时，后台写入器才会调用 sync_file_range 或 posix_fadvise 等函数，主动请求操作系统把已经写出的数据刷到磁盘。
这样设计的目的非常明确：一方面，数据库不希望每次写出一页就执行一次刷盘，那样会带来极高的随机 I/O 成本；另一方面，也不希望所有脏页都堆积在操作系统页缓存中，直到检查点或内核回写机制一次性冲刷，造成巨大的写入尖峰。因此，bgwriter_flush_after 相当于给后台写入器设置了一个刷盘刻度，用来在平滑写入和避免积压之间取得平衡。
该参数默认值为 512kB，在 postgresql.conf 中可以写成 512kB、64 或 1MB。如果不带单位，整数表示的是 8kB 块数量。将值设为 0 表示禁用后台写入器的主动刷盘。需要注意的是，这个参数只影响 bgwriter 主动扫描阶段的刷盘行为，检查点进程自己的刷盘阈值由 checkpoint_flush_after 单独控制，两者配合才能完整覆盖数据库写出路径。
二、如何判断当前设置是否合理
调节 bgwriter_flush_after 不能只凭感觉，需要结合 pg_stat_bgwriter 视图中的统计数据进行判断。这个视图里最值得关注的列包括 buffers_clean、maxwritten_clean、buffers_backend 和 buffers_checkpoint。其中 buffers_clean 表示后台写入器成功写出的缓冲页数量，maxwritten_clean 表示后台写入器因为达到 bgwriter_lru_maxpages 上限而停止扫描的次数。
如果 maxwritten_clean 增长非常快，说明后台写入器每次唤醒都写满了允许的最大页数，但仍然来不及清理脏页。这时问题通常不在 bgwriter_flush_after，而在 bgwriter_lru_maxpages 设置过小或 bgwriter_delay 间隔过长。此时即便大幅调整刷盘阈值，也不会明显改善写入压力。相反，如果 buffers_backend 长期保持较高水平，说明很多写操作由后端进程自己完成，后台写入器的清理能力不足，事务延迟可能因此上升。
在操作系统层面，可以使用 iostat -x 1 观察磁盘的 await、util 和队列长度。如果平时磁盘使用率很低，但在检查点发生时利用率突然冲到接近 100%，并且应用写入延迟同步飙升，通常意味着大量脏页积压到了检查点阶段才被强制刷盘。此时让 bgwriter_flush_after 保持一个适中值，可以帮助后台写入器提前分散一部分 I/O，减轻检查点瞬间的写盘压力。
一个常见误区是认为 bgwriter_flush_after 越小越好，甚至希望每次写出一页就立即刷盘。实际上，如果阈值设置得比如只有 64kB，后台写入器就会频繁触发刷盘请求，在机械盘上产生大量随机小块写，反而拖垮整体写入性能。另一个极端是直接设置为 0 禁用刷盘，认为这样可以避免额外 I/O，但最终这些脏页仍然会由检查点或内核回写处理，到那时瞬时 I/O 压力可能更加集中。
三、不同负载和存储介质下的调节建议
对于使用机械盘的实例，随机读写能力有限，IOPS 通常只有几百。建议从默认的 512kB 开始，甚至可以略微降低到 256kB，让 bgwriter 每累计 256kB 左右就请求一次刷盘，避免页缓存堆积过多。如果观察到 maxwritten_clean 增长较快，优先提高 bgwriter_lru_maxpages 到 200 或 300，而不是盲目调低 bgwriter_flush_after。机械盘上过于频繁的小块刷盘会造成磁头反复寻道，性能下降非常明显。
SATA SSD 的随机读写性能比机械盘好很多，但写入放大对寿命和性能仍有影响。建议将阈值设置在 512kB 到 1MB 之间，适当减少主动刷盘频率，让 SSD 控制器有机会合并写入操作。检查点进程的刷盘阈值可以单独配置为 checkpoint_flush_after = 256kB 或 512kB，与后台写入器形成阶梯，避免两个进程同时触发刷盘争抢磁盘带宽。
NVMe SSD 的吞吐和延迟都极高，可以尝试把 bgwriter_flush_after 提高到 2MB，甚至在写入压力不大的情况下直接禁用。但要注意，如果系统内存较大且内核脏页参数设置偏高，禁用后可能在检查点阶段出现较大的 I/O 突发。稳妥的做法是先设置为 1MB 观察一段时间，确认检查点停顿没有明显增加，再考虑进一步放大或禁用。
下面是一个针对 SATA SSD 中等写入负载的配置示例：
# postgresql.conf 中的后台写入器刷新配置 bgwriter_delay = 200ms bgwriter_lru_maxpages = 200 bgwriter_flush_after = 512kB # 检查点进程的刷盘阈值可以单独设置 checkpoint_flush_after = 256kB
修改完配置后，可以通过执行以下命令让参数生效，而不需要重启数据库：
SELECT pg_reload_conf();
除了数据库参数，Linux 内核中的 /proc/sys/vm/dirty_background_ratio 和 dirty_ratio 也会影响全局刷盘节奏。bgwriter_flush_after 是在数据库层面主动请求刷盘，而内核参数决定的是整机脏页水位。如果内核水位设置得过于激进，数据库的主动刷盘可能被内核的大规模回写淹没；如果内核水位设置得过于保守，又可能让数据库失去对刷盘时机的控制。调节时需要同时观察 /proc/meminfo 中的 Dirty 和 Writeback 数值，以确认当前系统脏页规模。
四、调节后的验证方法与效果观察
参数修改之后，不能只看配置是否生效，还要验证写入行为是否真的发生了预期变化。可以先记录一组 pg_stat_bgwriter 的基准数据，然后在相同负载下对比调节前后的差值。下面 SQL 可以用于查看后台写入器的主要统计信息：
SELECT buffers_clean, maxwritten_clean, buffers_backend, buffers_checkpoint, buffers_alloc FROM pg_stat_bgwriter;
在测试环境中，还可以使用 pg_stat_reset_shared('bgwriter') 重置后台写入器统计，方便观察一段时间内的精确变化，但生产环境应谨慎使用。重置后运行一段代表性负载，再查看上述指标，如果 buffers_clean 增大而 buffers_backend 下降，说明后台写入器承担了更多的写出工作，通常对事务延迟更有利。与此同时，buffers_checkpoint 的变化可以反映检查点期间的压力是否得到缓解。
最终判断调节是否成功，还应回归到业务指标上。检查点发生期间的写入延迟、磁盘队列长度、应用侧的平均响应时间和 P99 延迟都是重要参考。如果检查点附近的磁盘利用率不再长时间维持在高位，应用写入抖动减少，说明刷盘阈值调节起到了预期效果。反之，如果后台写入量增加了很多，但检查点停顿没有改善，就需要考虑是否还有 checkpoint_completion_target、max_wal_size 等参数需要协同调整。
调节 bgwriter_flush_after 并没有一个适用于所有环境的固定最优值。它的合理范围取决于磁盘类型、写入模式、检查点配置以及操作系统回写参数。通常可以从默认的 512kB 出发，每次只调整一个变量，并结合 pg_stat_bgwriter 和系统 I/O 监控进行观察，逐渐找到适合当前业务负载的刷盘节奏。
PostgreSQLbgwriter_flush_after刷盘修改时间：2026-08-27 02:35:56