PostgreSQL 10.1 手册

  • 时间:
  • 浏览:5

在归档恢复模式或后备模式,服务器周期性地执行重启点。和正常操作时的检查点类似于 :服务器强制它所有的情况到磁盘,更新pg_control来指示已被正确处理的WAL数据需要被再次扫描,怎么才能 让接着回收pg_wal中的任何旧日志段文件。重启点的执行频率只能高于主机中检查点的执行频率,愿因重启点只能在检查点记录处要能被执行。 愿因从最后一三个白多重启点完后 过去了大约 checkpoint_timeout秒愿因 WAL 尺寸快要达到max_wal_size,则会到达一三个白多检查点,这就有触发一三个白多重启点。不过,愿因对于什么过可不上能只能执行一三个白多重启点有限制,在恢复期间max_wal_size常常被超过,最多会超过一三个白多检查点周期间的 WAL(不管怎么才能 才能 ,max_wal_size从来就有一三个白多硬限制,怎么才能 让你应该一直应该留出富有的净空来正确处理耗尽磁盘空间)。

为了正确处理大批页面写入对I/O系统产生的冲击,一三个白多检查点中对脏缓冲区的写出操作被散布到一段时间上。你你是什么 时间段由checkpoint_completion_target控制,它用检查点间隔的一三个白多分数表示。I/O率将被调整,以便能按照要求完成检查点:当checkpoint_timeout给定的秒数愿因过去,愿因max_wal_size被超过完后 会地处检查点,以先达到的为准。默认值为0.5,PostgreSQL被期望要能在下一三个白多检查点启动完后 的大约 一八时间内完成每个检查点。在一三个白多接近于正常操作期间最大I/O的系统上,你愿因希望增加checkpoint_completion_target来降低检查点的I/O负载。但你你是什么 做法的缺点是被延长的检查点愿因影响恢复时间,愿因需要保留更多WAL段来用于愿因的恢复操作。尽管checkpoint_completion_target能只能被设置为高于1.0,但最好还是让它小于1.0(你说那先 最多0.9),愿因检查点还包含除了写出脏缓冲区之外的或多或少或多或少动作。1.0的设置极有愿因愿因检查点只能按时被完成,这愿因愿因所需的WAL段数量意外变化愿因性能损失。

检查点的代价相对比较昂贵,首先愿因它们要求写出所有当前为脏的缓冲区,正如以上讨论的,第三个白愿因是它们会愿因额外的WAL流量。怎么才能 让比较明智的做法是将检查点参数设置得足够高,怎么才能 让检查点就不要再过于频繁地地处。让你设置checkpoint_warning参数作为对于你的检查点参数的并就有简单删改性检查。愿因检查点的地处时间间隔比checkpoint_warning秒需要接近,一三个白多消息愿因被发送到服务器日志来推荐你增加max_wal_size。偶尔一直再次出现的怎么才能 让的消息并就有会愿因警报,怎么才能 让愿因它一直再次出现得太频繁,越来越 就应该增加检查点控制参数。 愿因你越来越 把max_wal_size设置得足够高, 越来越 在进行如大型COPY传输等批量操作的完后 愿因会愿因一直再次出现少量类似于 的警告消息。

有好多个WAL相关的配置参数会影响数据库性能。本节将解释它们的使用。关于服务器配置参数的设置的一般信息请参考第 19 章。

检查点对于刷写所有脏数据页到磁盘的要求愿因会愿因可观的I/O负载。出于你你是什么 愿因,检查点活动是被有所限制的,怎么才能 让I/O在检查点过后开始了时过后开始了怎么才能 让能在下一三个白多检查点将要过后开始了之间完成,这使得检查点期间的性能下降被最小化。

commit_delay定义了一三个白多组提交领导者多多任务管理器 在XLogFlush中要求一三个白多锁完后 愿因休眠的微秒数,而组提交追随者都排队等待在领导者完后 。怎么才能 让的延迟能只能允许其它服务器多多任务管理器 把它们提交的记录追加到WAL缓冲区中,怎么才能 让所有的那先 记录愿因被领导者的最终同步操作刷出。愿因fsync被禁用愿因当前地处活跃事务中的会话数少于commit_siblings,休眠将不要再地处;怎么才能 让就正确处理了在其它事务不要再调快提交的情况下进行休眠。 请注意在或多或少平台上,休眠要求的单位是十毫秒,要是 任何介于 1 和 500 微秒之间的非零commit_delay设置的作用就有一样的。 需要注意在或多或少平台上,休眠操作用的时间会比该参数所请求的要略长或多或少。

启用wal_debug配置参数(前提是PostgreSQL编译的完后 打开了你你是什么 支持) 将愿因每次XLogInsertRecordXLogFlush WAL调用都被记录到服务器日志。你你是什么 选项完后 愿因会被更通用的机制取代。

愿因commit_delay的目的是允许每次刷写操作的开销要能在并发提交的事务之间进行分摊(愿因会以事务延迟为代价),在要能明智地选者该设置完后 有必要对代价进行量化。代价越高,在一定程度上commit_delay对于提高事务吞吐量的效果就越好。pg_test_fsync多多任务管理器 能只能被用来衡量一次WAL刷写操作需要的平均微秒数。该多多任务管理器 报告的一次8kB写操作后的刷出所用的平均时间的一半常常是commit_delay最有效的设置,怎么才能 让在优化并就有特定工作负荷时,该值被推荐为起始点。当WAL日志被存储在高延迟的旋转磁盘上时,调节commit_delay有点硬有效,即使在具有非常快同步时间的存储介质上要能得到很显著的收益,类似于 固态驱动器或具有电池后备写高速缓存的RAID阵列。怎么才能 让这应该在一三个白多具有代表性的工作负荷下进行明确地测试。较高的commit_siblings值应该用在你你是什么 情况中,反之较小的commit_siblings值通常对高延迟介质有用。注意过低的commit_delay设置也很有愿因增加事务延迟甚至于整个事务吞吐量就有受到影响。

wal_sync_method参数决定PostgreSQL怎么才能 才能 请求内核强制将WAL更新到磁盘。怎么才能 让我满足可靠性,越来越 除了fsync_writethrough所有选项应该就有一样的,fsync_writethrough能只能在或多或少完后 强制磁盘高速缓存的刷写,而或多或少选项只能怎么才能 让做。不过,哪种选项最快则愿因和平台密切相关。 让你使用pg_test_fsync多多任务管理器 来测试不同选项的效率。请注意愿因你关闭了fsync,越来越 你你是什么 参数就无所谓了。

50.4. WAL配置

在 Linux 和 POSIX 平台上,checkpoint_flush_after允许强制 OS 超过一三个白多可配置的字节数后将检查点写入的页面刷入磁盘。怎么才能 让,那先 页面愿因会被保留在 OS 的页面缓存中,当检查点过后开始了发出fsync时就会愿因少量刷写形成延迟。你你是什么 设置通常能够减小事务延迟,怎么才能 让它也愿因对性能带来负面影响,尤其是对于超过shared_buffers但小于 OS 页面缓存的负载来说更是越来越 。

降低checkpoint_timeout和/或max_wal_size会愿因检查点更频繁地地处。这使得崩溃后恢复调快,愿因需要重做的工作更少。怎么才能 让,朋友需要在你你是什么 点和增多的刷写脏数据页开销之间做出平衡。愿因full_page_writes被设置(默认情况),则还有一三个白多因素需要考虑。为了确保数据页一致性,在每个检查点完后 对一三个白多数据页的第一次修改将愿因整个页面内容被日志记录。在这情况下,一三个白多较小的检查点间隔会增加输出到WAL日志的容量,这让使用较小间隔的效果打了折扣怎么才能 让将愿因更多的磁盘I/O。

本文转自PostgreSQL中文社区,原文链接:50.4. WAL配置

检查点是在事务序列中的点,你你是什么 点保证被更新的堆和索引数据文件的所有信息在该检查点完后 已被写入。在检查点时刻,所有脏数据页被刷写到磁盘,怎么才能 让一三个白多特殊的检查点记录将被写入到日志文件(修改记录完后 愿因被刷写到WAL文件)。在崩溃时,崩溃恢复过程检查最新的检查点记录用来决定从日志中的哪或多或少(称为重做记录)过后开始了REDO操作。在你你是什么 点完后 对数据文件所做的任何修改都愿因被保证地处磁盘之上。怎么才能 让,完成一三个白多检查点后地处包含重做记录的日志段完后 的日志段就不再需要了,能只能将其回收或删除(当WAL归档工作时,日志段在被回收或删除完后 需要被归档)。

独立于max_wal_size之外,wal_keep_segments + 1 个最近的 WAL 文件将一直被保留。还有,愿因使用了 WAL 归档,旧的段在被归档完后 只能被移除愿因再利用。愿因 WAL 归档无法跟上产生 WAL 的步伐,愿因愿因archive_command重复失败,旧的 WAL 文件将要素在pg_wal中,直到该情况被正确处理。一三个白多使用了好友克隆槽的较慢愿因失败的后备服务器也会带来同样的效果(见第 26.2.6 节)。

服务器的检查点多多任务管理器 常常自动地执行一三个白多检查点。检查点在每checkpoint_timeout秒过后开始了,愿因在快要超过 max_wal_size时过后开始了。 默认的设置分别是 5 分钟和 1 GB。愿因怎么才能 让一三个白多检查点以来越来越 WAL被写入, 则即使过了checkpoint_timeout新的检查点也会被跳过( 愿因正在使用WAL归档怎么才能 让你想对文件被归档频率设置一三个白多较低的限制来约束 潜在的数据丢失,你应该调整archive_timeout 参数而就有检查点参数)。要能只能使用SQL命令 CHECKPOINT来强制一三个白多检查点。

commit_delay被设置为0(默认值),仍然有愿因一直再次出现组提交的形式,怎么才能 让组中的成员只能是那先 在前一三个白多刷写操作地处过程窗口中需要刷写它们提交记录的会话。在较高的客户端数量时很愿因地处gangway effect,怎么才能 让即使commit_delay为0,组提交的效果也很显著,怎么才能 让显式地设置commit_delay愿因越来越 作用。设置commit_delay只能在并就有情况下有帮助:(1)有或多或少并发提交的事务,以及(2)吞吐量在并就有程度上被提交率限制。怎么才能 让在高旋转延迟的设备上,即使少到只能一三个白多客户端,该设置要能有效提高事务吞吐量。

pg_wal目录中的 WAL 段文件数量取决于min_wal_sizemax_wal_size以及在完后 的检查点周期中产生的 WAL 数量。当旧的日志段文件不再被需要时,它们将被移除愿因被再利用(也怎么才能 让被重命名变成数列中未来的段)。愿因愿因日志输出率的短期峰值愿因超过max_wal_size,需要的段文件将被移除直到系统回到你你是什么 限制以下。低于该限制时,系统会再利用足够的 WAL 文件来覆盖直到下一三个白多检查点完后 的需要。你你是什么 需怎么才能 让基于完后 的检查点周期中使用的 WAL 文件数量的移动平均数估算出来的。愿因实际用量超过估计值,移动平均数会立即增加,怎么才能 让它能在一定程度上适应峰值用量而就有平均用量。min_wal_size对回收给未来使用的 WAL 文件的量设置了一三个白多最小值,你你是什么 参数指定数量的 WAL 将一直被回收给未来使用,即便系统很闲怎么才能 让 WAL 用量估计建议只需要或多或少点 WAL 时也是越来越 。

有一三个白多常用的结构WAL函数:XLogInsertRecordXLogFlush。 XLogInsertRecord用于向共享内存中的WAL缓冲区里放置一三个白多新记录。愿因越来越 空间存放新记录, 越来越 XLogInsertRecord就不得不写出(向内核缓存里写)或多或少填满了的WAL缓冲区。 这并就有朋友所期望的,愿因XLogInsertRecord用于每次数据库低层修改(比如,记录插入)时就有在受影响的数据页上持有一三个白多排它锁,愿因该操作需要越来越快越好。但糟糕的是, 写WAL缓冲愿因就有强制创建新的日志段,这花的时间甚至更多。通常,WAL缓冲区应该由一三个白多XLogFlush请求来写和刷出, 在大要素完后 它就有地处在事务提交的完后 以确保事务记录被刷写到永久存储。在那先 日志输出量比较大的系统上,XLogFlush请求愿因过低频繁,怎么才能 让就只能正确处理XLogInsert进行写操作。在怎么才能 让的系统上,朋友应该通过修改配置参数 wal_buffers的值来增加WAL缓冲区的数量。愿因设置了 full_page_writes怎么才能 让系统相当繁忙, 把wal_buffers设置得更高或多或少将能够在紧随每个检查点完后 的时间段里得到平滑的响应时间。