--POSTGRESQL FULL PAGE 优化 与 CHECKPOINT 的“矛盾”!

--POSTGRESQL FULL PAGE 优化 与 CHECKPOINT 的“矛盾”!_第1张图片

在说完mysql 不要关DW 后,祭出 POSTGRESQL FULL PAGE 的确是有点不厚道,所以必然会引出 FULL PAGE 也存在性能问题的话题。到底是大公鸡和大马猴的问题,还是小绵羊的牧羊犬的故事。

首先FULL PAGE 和 MYSQL的 DW 一样,都是为了解决数据库CRASH 时数据的那一刻存在的缺失问题。我看来看看相关的解释

PostgreSQL 在 checkpoint 之后在对数据页面的第一次写的时候会将整个数据页面写到 xlog 里面。当出现主机断电或者OS崩溃时,redo操作时通过checksum发现“部分写”的数据页,并将xlog中保存的这个完整数据页覆盖当前损坏的数据页,然后再继续redo就可以恢复整个数据库了。

看完以后会突然冒出一个想法

1 checkpoint 越密集,那FULL PAGE 也就越多咯

2 FULL PAGE 第一个页面的大小会影响写性能

那我关掉FULL PAGE 不就好了

当然不是,FULL  PAGE 在某些时候,不是你要开就开,要关就关的,尤其你在操作  pg_basebackup(或者一连串利用这命令的伪装者们)的操作时 FULL PAGE 是强制打开的,到底为什么这就不解释了,和 备份的原理有关。

其实这个想法是比较巧妙的,他仅仅针对CHECK POINT 的第一个页面进行检测并写入到 XLOG 中

--POSTGRESQL FULL PAGE 优化 与 CHECKPOINT 的“矛盾”!_第2张图片

而提出异议或否定的意见是,full_page_write需要在xlog(wal)中记录数据页,会进行更多写操作,不仅数据变,还有数据页的信息,这会增加的IO和磁盘消耗,引起主备延迟变大。

另外具体相关的FULL PAGE 的解释和讲解,参见下边的图,如有需要(可以入群,免费下载相关书籍)

--POSTGRESQL FULL PAGE 优化 与 CHECKPOINT 的“矛盾”!_第3张图片

于此同时,很多的优化的方法就来了 ,有一种就很像 MYSQL的 DW 的方式来优化PG 的FULL PAGE 方式, 但需要在PG上打PATCH。(这里不详细展开)

另外降低CHECKPOINT 的频率也可以降低 FULL PAGE 所带来的性能影响,也有提出将PG的数据页面在编译的时候变小(个人觉得有点过了), 当然这还不是终极的优化方法,还有的文章中提出了,使用序列,与 UUID 对FULL PAGE 的不同的性能影响,其中指出,如果使用序列的方式,则在插入同样行数的数据时,对比 UUID ,产生的WAL 的大小相差20倍。

--POSTGRESQL FULL PAGE 优化 与 CHECKPOINT 的“矛盾”!_第4张图片

其中关键的一段话在上,提出如果使用序列的方式作为主键,则插入到btree索引中的相同叶页面,只有对页面的第一次修改才会触发整个页面的写入。UUID是完全不同的情况,UUID值完全不是连续的,实际上每次插入都可能接触到全新的叶索引叶页面,造成写入日志的量大影响I/O的性能。

上文中也提出可以调整 CHECK POINT 的间距,来降低FULL PAGE 造成的影响,具体怎么调整CHECK POINT 的间距。

--POSTGRESQL FULL PAGE 优化 与 CHECKPOINT 的“矛盾”!_第5张图片

上面是我们在每个PG 中都能看到的与CHECKPOINT 有关的东西,在一个负载很重的系统中,我们是否可以将MAX_WAL_SIZE 调大,(有人可能会问这个数字初期是怎么来的,那我觉得你可能对PG的安装方面还可以在了解一下),调整到多大,8 - 10G 是没有问题的。增加检查点之间的距离可以减少WAL -但是为什么会发生这种情况呢?请记住:将事务日志放在首位的目的是确保系统在崩溃后仍然能够正常运行。将WAL中的这些更改应用到数据文件将修复数据文件并在启动时恢复系统。为了安全起见,PostgreSQL不能简单地记录对一个块所做的更改—如果一个块在通过检查点后第一次被更改,那么整个页面都必须被发送到WAL。

两个检查点之间的距离不仅由于检查点的减少而提高了速度,更少的检查点还会影响所写事务日志的数量。所以在优化FULL PAGE 的时候是要考虑,降低检查点,其实这和 MYSQL 里面调整innodb log file size 是一个意思。

在 Postgresql 11 Administratoration Cookbook, 这本书中的427页也中对这两个参数也有相关的讲解,

两个参数控制CHECKPOINT发生的频率与预期,首先checkpoint_timout 这个参数会触发在上一次CHECKPOINT 发生后多少秒后,进行HECKPOINT,这直接影响有多少量的 WAL data 将要写入目标文件,实际上控制WAL写入的数量的参数有两个地方 

MAX_WAL_SIZE 

CHECKPOINT_TIMEOUT

然而当你调大参数,你应该考虑系统如果CRASH 后的恢复时间,与多长时间做一次CHECKPOINT 之间做一个衡量,并且也要考虑WAL 日志的空间在磁盘上是否有充足的空间。

同时除2个参数可以优化FULL PAGE 的性能的同时,是否还有其他的方法,我们知道 WAL 日志的也是有缓冲,默认是同步提交,只要是有COMMIT 日志信息就会刷入到磁盘, wal_buffers可以调整wal_buffer 的大小,并且调整 synchronous_commit  不在同步提交,减少磁盘交互,但这会打破系统CRASH 后的数据库安全,有数据库丢失的风险。

--POSTGRESQL FULL PAGE 优化 与 CHECKPOINT 的“矛盾”!_第6张图片

那怎么有的放矢的更大利用wal_buffers ,可以根据业务,在某些情况下,通过调整下面的参数在session 的级别,来对某些可以容忍 1秒内数据库丢失的情况中,将syschronous_commit = off.

--POSTGRESQL FULL PAGE 优化 与 CHECKPOINT 的“矛盾”!_第7张图片

有问题可以一期解决,欢迎加入, 共享电子书请随意

--POSTGRESQL FULL PAGE 优化 与 CHECKPOINT 的“矛盾”!_第8张图片

你可能感兴趣的:(--POSTGRESQL FULL PAGE 优化 与 CHECKPOINT 的“矛盾”!)