PostgreSQL的pg_stat_bgwriter视图

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写比例偏高，那么尝试加大这个参数还是有效的。