11.3. WAL 配置

有几个与 WAL 相关的参数会影响数据库性能． 本节讨论它们的使用．参阅 Section 3.4 获取配置参数的细节．

有两个常用的 WAL 函数： LogInsert 和 LogFlush ． LogInsert 用于向共享内存中的 WAL 缓冲区里加一条新的记录．如果没有空间存放 新记录，那么 LogInsert 就不得不写出 （向内核缓存里写）一些填满了的 WAL 缓冲． 我们可不想这样，因为 LogInsert 用于 每次数据库低层修改（比如，记录插入），都要花在受影响的数据页 上持有一个排它锁的时间，因为该操作需要越快越好；更糟糕的是， 写 WAL 缓冲可能还会强制创建新的日志段， 它花的时间甚至更多．通常， WAL 缓冲区应该由 一个 LogFlush 请求来写和冲刷， 在大部分时候它都是发生在事务提交的时候以确保事务记录被冲刷到 永久存储器上去了．在那些日志输入量比较大的系统上， LogFlush 请求可能不够频繁，这样就不能避免 WAL 缓冲区被 LogInsert 写．在这样的系统上，我们应该通过修改 WAL_BUFFERS 参数的值来增加 WAL 缓冲区的数量．缺省的 WAL 缓冲区数量是 8． 增加这个数值将有对应的共享内存使用量的增加．

检查点（Checkpoints） 是事务的顺序的点， 我们保证在该点之前的所有日志信息都更新到数据文件中去了． 在检查点时，所有脏数据页都冲刷到磁盘并且向日志文件中写入一条 特殊的检查点记录．结果是，在发生崩溃的时候，恢复器就知道 应该从日志中的哪条记录（称做 redo 记录）开始做 REDO 操作， 因为在该记录前的对数据文件的任何修改都已经在磁盘上了． 在完成检查点处理之后，任何在 undo 记录之前写的日志段都不再 需要，因此可以循环使用或者删除．(到基于 WAL 的 BAR (备份和恢复)实现的时候，这些日志在 循环利用或者删除之前将先归档．)

检查点制造器也可以为将来使用创建几个日志段， 这样就可以避免在创建它们的时候的 LogInsert 或者 LogFlush 花费时间．(如果出现了上面的情况， 那么整个数据库都将被创建操作延迟，因此如果这些文件可以在检查点 制造器创建，那么会更好一些，因为这个时候所有人都不处于关键时刻．) 缺省时，只有在当前的段中已经有超过 75% 的空间被使用的时候才创建一个 新的 16MB 的段文件．如果系统在检查点之间生成了超过 4MB 的日志输出， 那么这样的新日志段是不够的． 但是我们可以命令服务器在检查点时预先创建多达 64 个日志段， 方法是修改 WAL_FILES 配置参数．

postmaster 每隔一段时间就 排生一个特殊的进程以创建下一个检查点． 每隔 CHECKPOINT_SEGMENTS 个日志段就创建一个检查点， 或者每隔? CHECKPOINT_TIMEOUT 秒创建一个． 以先到为准．缺省设置分别是 3 个段和 300 秒． 我们也可以用 SQL 命令 CHECKPOINT 强制一个检查点．

减少 CHECKPOINT_SEGMENTS 和/或 CHECKPOINT_TIMEOUT 会令检查点更频繁一些． 这样就允许更快的崩溃后恢复(因为需要重做的工作更少)．不过， 我们必须在这个目地和更频繁地冲刷脏数据页所带来的额外开销之间 取得平衡．另外，为了保证数据页的一致性，在每个检查点之后的第一次 数据页的变化会导致对整个页面内容的日志记录．因此，检查点时间间隔 短了会导致输出到日志中的数据的增加，会抵销一部分缩短间隔的目标， 并且怎么着都会产生更多的磁盘 I/O．

16MB 段文件的数目将总是至少 WAL_FILES + 1， 并且通常不会超过 WAL_FILES + 2 * CHECKPOINT_SEGMENTS +1． 这些公式可以用于估计 WAL 需要的空间．最初，如果一个旧的日志段文件不再 需要了，那么它是得到循环使用(重命名为顺序的下一个可用段)．如果由于 短期的日志输出峰值导致了超过 WAL_FILES + 2 * CHECKPOINT_SEGMENTS + 1 个段文件， 那么不再需要的段文件将被删除，而不是循环使用，直到系统回复到这个限制 之下．(如果这种现象经常出现，那么你应该增加 WAL_FILES 以避免它．删除那些稍后又要重新创建的日志段是昂贵而且无意义的操作．)

COMMIT_DELAY 定义了后端在使用 LogInsert 向日志中写了一条已提交 的记录之后，在执行一次 LogFlush 之前休眠 的毫秒数．这样的延迟可以允许其它的后端把它们提交的记录追加 到日志中，这样就可以用一次日志同步把所有日志冲刷到日志中． 如果没有打开 fsync 或者当前少于 COMMIT_SIBLINGS 个其它后端处于活跃事务状态的时候则不会发生休眠； 这样就避免了在其它事务一时半会不会提交的情况下睡眠． 请注意在大多数平台上，休眠要求的分辩率是十毫秒， 所以任何介于 1 和 10000 微秒之间的非零 COMMIT_DELAY 的作用都是一样的． 适用这些参数的比较好的数值还不太清楚；我们鼓励你多做试验．

WAL_SYNC_METHOD 参数决定 PostgreSQL 如何 请求内核强制将 WAL 更新输出到磁盘．只要满足可靠性，那么 所有选项应该都是一样的，但是哪个最快则可能和平台密切相关． 请注意如果你关闭了 FSYNC ，那么这个参数 就无所谓了．

把 WAL_DEBUG 参数设置为任何非零值都会导致 每次 LogInsert 和 LogFlush WAL 调用都被记录到标准错误．目前，这个非零值是多少 没有什么区别．这个选项以后可能会被更通用的机制取代．