pg_stat_bgwriter视图提供了一组共享缓冲区写入方面性能数据。
=#select * from pg_stat_bgwriter; -[ RECORD 1 ]---------+----------------------------- checkpoints_timed | 15462 #计划检查点的发生次数，这种检查点是checkpoint_timeout参数规定的超时达到后系统启动的checkpoint； checkpoints_req | 148 #非计划检查点的次数，包含手动的检查点、xlog(redo日志)检查点(指当某些数据库预定的阈值达到时启动的检查点，比如WAL已经超出了max_wal_size或者checkpoint_segments，也会触发xlog ckpt) checkpoint_write_time | 2130524730 #检查点写入的总时长 checkpoint_sync_time | 72082 #检查点同步文件的总时长 buffers_checkpoint | 174657791 #检查点清理的脏块 buffers_clean | 0 #bgwriter清理的脏块数量 maxwritten_clean | 0 #bgwriter清理脏块的时候达到bgwriter_lru_maxpages后终止写入批处理的次数，为了防止一次批量写入太大影响数据块IO性能，bgwriter每次都有写入的限制。不过这个参数的缺省值100太小，对于负载较高的数据库，需要加大； buffers_backend | 24491898 #backend清理的脏块数量 buffers_backend_fsync | 2 #backend被迫自己调用fsync来同步数据的计数，如果这个计数器不为零，说明当时的fsync队列已经满了，存储子系统肯定出现了性能问题； buffers_alloc | 51275374 #buffer分配的次数 stats_reset | 2021-01-29 14:41:48.97647+08 #上一次RESET这些统计值的时间 =#
PG的bgwriter、checkpointer和backend都可能把脏数据回写到存储上。
正常情况下，我们希望大部分的脏数据都是bgwriter写回存储的，少量的脏数据是checkpointer写入的，更少的数据是backend写入的。因为backend写入数据是十分高成本的。不过好像事实上并非如此，backend写入的比例很高。
不过对于DBA来说，应该尽可能地通过调整降低backend回写脏块的数量。我们需要分析一下产生这种情况的原因。比如，如果shared buffer上设置偏低，会导致缓冲块还没等到bgwriter和checkpointer回写，就被backend找到并要进行重用那个了。
bgwriter相关的几个参数：
·bgwriter_delay:bgwriter两个任务之间的休眠时间的初始值为200毫秒；
·bgwriter_lru_maxpages:每次bgwriter任务写buffer的最大page数，一旦达到这个数量，bgwriter就结束任务开始休息，也就是说bgwriter休眠200毫秒，然后写入几十毫秒就又开始了休息；
·bgwriter_lru_multiplier：这个参数用于评估下一次写任务的数量，其依据是这段时间内新申请的buffer数量的倍数，如果这个参数乘以新增加buffer分配的数量后小于bgwriter_lru_maxpages，那么有可能下一个写任务的数量会小于预期的写入量。将这个参数调大，会增加bgwriter回写脏块的数量，不过会增加写IO压力，将这个参数调小，可以降低写IO压力，不过可能导致backend写脏块的比例增加。不同负载的系统中，这个参数的值应该是需要做调整的，而不是只是用缺省值2。如果你发现你的系统的写IO压力还不大，但是 bgwriter写比例偏低，backend写比例偏高，那么尝试加大这个参数还是有效的。