如何利用pg_stat_bgwriter视图分析PostgreSQL检查点与缓冲区统计？

PostgreSQL的性能问题很多时候不是SQL写得不好，而是底层IO机制没有运转顺畅。检查点（checkpoint）和后台写进程（bgwriter）共同负责脏页的刷写，一旦它们的工作节奏出了问题，表现往往是周期性的IO尖刺、TPS抖动。要判断这类问题，第一个该看的工具就是pg_stat_bgwriter视图。这篇文章详细拆解这个视图的各个字段，并给出分析方法和调优建议。

pg_stat_bgwriter视图的字段含义

pg_stat_bgwriter是一个统计视图，从服务器启动（或最后一次统计重置）开始，累计记录后台写进程和检查点的活动数据。在PostgreSQL 15之前的版本中，它把检查点统计和缓冲区统计放在同一个视图里；15之后部分字段被拆分到了pg_stat_checkpointer视图，这一点在分析时要先确认自己的版本。

视图的核心字段大致可以分为三组。第一组是检查点相关的：checkpoints_timed表示按时间间隔自动触发的检查点次数，checkpoints_req表示因WAL总量达到max_wal_size等条件被迫触发的检查点次数。第二组是写入时间：checkpoint_write_time是检查点过程中写脏页消耗的总毫秒数，checkpoint_sync_time是fsync阶段消耗的总毫秒数。第三组是缓冲区统计：buffers_checkpoint、buffers_backend、buffers_clean分别代表由检查点、后端进程自身、bgwriter写出的缓冲区数量。

其中有一个字段特别值得单独说明：maxwritten_clean记录bgwriter因为单轮写入量超过bgwriter_lru_maxpages而提前停止的次数。如果这个数字持续增长，说明bgwriter的写入能力配置得太保守，脏页清理速度跟不上产生速度。

-- 查看视图的完整内容
SELECT * FROM pg_stat_bgwriter;

-- 计算两个采样点之间的差值，比直接看累计值更有意义
SELECT
    checkpoints_timed,
    checkpoints_req,
    buffers_checkpoint,
    buffers_backend,
    buffers_clean,
    maxwritten_clean
FROM pg_stat_bgwriter;

如何判断检查点是否过于频繁

检查点本身是必要的，但频繁的检查点会带来严重的性能开销。每次检查点发生时，所有脏页都要刷到磁盘，之后还有一轮密集的fsync。如果检查点接二连三地发生，数据库就会陷入“写入-刷盘-再写入”的循环，IO始终降不下来。

判断的关键是看checkpoints_req和checkpoints_timed的比例。理想情况下，绝大多数检查点应该由定时器触发（timed），也就是每隔checkpoint_timeout才执行一次，这样的检查点节奏是可控的。如果checkpoints_req占比超过两三成，说明WAL产生速度太快，系统频繁触碰max_wal_size上限被迫做检查点，这时需要考虑增大max_wal_size或者优化写入量大的业务SQL。

另一个观察角度是平均每次检查点的写入时间。用checkpoint_write_time除以检查点总次数，可以得到单次检查点的平均写盘耗时；用checkpoint_sync_time做同样的计算，可以评估fsync阶段的压力。如果sync时间占比很高，说明脏页集中在一个短时间窗口内刷写，这时调整checkpoint_completion_target往往有效。该参数默认值为0.9，意思是让检查点在两次检查点间隔的90%时间内匀速完成刷写，把IO压力摊平，避免末尾出现IO风暴。

-- 计算被迫触发的检查点占比
SELECT
    checkpoints_timed,
    checkpoints_req,
    round(100.0 * checkpoints_req /
        nullif(checkpoints_timed + checkpoints_req, 0), 2)
        AS req_percent,
    round(checkpoint_write_time /
        nullif(checkpoints_timed + checkpoints_req, 0), 1)
        AS avg_write_ms,
    round(checkpoint_sync_time /
        nullif(checkpoints_timed + checkpoints_req, 0), 1)
        AS avg_sync_ms
FROM pg_stat_bgwriter;

如果req_percent长期高于20%，就应该动手干预。常见的调整路径是：先确认checkpoint_timeout是否设置得太短（很多系统还在用默认的5分钟），适当延长到15到30分钟；再相应放大max_wal_size，给WAL留出足够的增长空间。两者配合调整后，重置统计视图观察一段时间，验证效果。

缓冲区写入分布与bgwriter调优

检查点之外，脏页的另一个出口是后端进程自己写。buffers_backend统计的就是后端进程为了复用缓冲区而不得不亲自把脏页刷出去的次数。这个数字偏高不是好事，因为后端进程是用户会话，让它去做刷盘的脏活，意味着用户查询会被IO阻塞，直接拉高响应时间。

健康的状态应该是buffers_clean（bgwriter写出的）和buffers_checkpoint占大头，buffers_backend占比较小。可以计算三者在总写入量中的占比来评估。如果backend占比超过一半，通常有两种原因：一是shared_buffers太小，可供复用的干净页不够；二是bgwriter的工作强度参数设置得太低，来不及在后台把脏页清理掉，只好让后端进程自己动手。

bgwriter有三个关键参数。bgwriter_delay控制每轮清理的间隔，默认200毫秒；bgwriter_lru_maxpages限制单轮最多写多少个缓冲区；bgwriter_lru_multiplier是一个启发式系数，bgwriter根据近期缓冲区的使用趋势估算下一轮需要清理的数量，再乘以这个系数。调优的常见做法是：如果maxwritten_clean持续增长且buffers_backend占比高，就逐步调大bgwriter_lru_maxpages，让每轮能写更多页。

-- 分析缓冲区写入分布
SELECT
    buffers_checkpoint,
    buffers_clean,
    buffers_backend,
    round(100.0 * buffers_backend /
        nullif(buffers_checkpoint + buffers_clean + buffers_backend, 0), 2)
        AS backend_percent
FROM pg_stat_bgwriter;

-- 统计归零，方便重新观察一个时段
SELECT pg_stat_reset();

还有一点容易被忽视：如果buffers_backend_fsync大于0，说明后端进程在执行fsync时不得不等待其他fsync完成，这通常是磁盘IO能力已经严重不足的信号，调参数只能缓解，根本上要考虑升级存储或降低写入压力。另外要注意，重置统计会清掉整个数据库的统计信息，生产环境操作前先评估影响，更稳妥的方式是定时把快照存到自己的采集表里，通过两次快照的差值做分析。

综合来看，pg_stat_bgwriter的价值在于它把不可见的IO机制量化成了可读的数字。养成定期采集这个视图的习惯，配合日志中的checkpoint记录，就能在性能问题爆发之前发现检查点节奏和缓冲区写入的异常，把调优做在前面。

PostgreSQLpg_stat_bgwriter检查点修改时间：2026-09-15 08:10:32