从PG15 WAL压缩优化说起

从PG15 WAL压缩优化说起

PG 15传闻中的超级令人激动的功能大多数跳票了，年初我也写过一个关于PG15新功能跳票的文章。PG 15 BETA已经发出几个月了，似乎PG 15里令人激动人心的功能不多，不过从长长的新功能列表里，我还是能够从中学到不少东西。数据库的发展是和现代硬件技术的发展密切相关的，而数据库在某一个方面的突破，可以为应用提供更大的舞台，让应用能够更加适应某些特定场景。

实际上经过几个重要特性的跳票之后，我对PG 15的期待最主要集中在FULL PAGE WRITE的优化上了。以前我也多次写文章研究过PG的WAL产生以及CHECKPOINT对高负载应用写入性能的影响。其实这些性能影响大部分来自于FULL PAGE WRITE。因为当某个脏块在CHECKPOINT完成后的第一次被写入的时候，都需要做一次FULL PAGE WRITE，以避免数据库需要恢复时出现块断裂的情况。而FULL PAGE WRITE大规模产生的时候，因为WAL的写入量大大增加，就会导致高并发写应用的性能问题。实际上，当我们在做pg_basebackup等在线备份操作时，也是会引发大量的FULL PAGE WRITE的。缓解这个问题的方法是加大CHECKPOINT的延时，让两次CHECPOINT的间隔更长一些，这样就会大量减少FULL PAGE WRITE。

加大CHEKPOINT的延时也是一个双刃剑，因为这会让数据库在恢复时需要RECOVER更多的页，同时也会在一个CHECKPOINT时集中写入大量的数据块。在瞬时对IO产生更大的影响。

在PG中关闭FULL PAGE WRITE也是一个选项，只不过需要找到支持PG关闭FULL PAGE WRITE的文件系统或者存储系统。我们以前曾经在ZFS上尝试过关闭FULL PAGE WRITE，效果是相当不错的。只不过在我们的大多数PG运行环境中并没有使用ZFS，因此对于PG 15在FULL PAGE WRITE上的优化，我们还是很期待的。

我曾经也考虑过通过WAL压缩来缓解FULL PAGE WRITE的问题，在PG 12上我们做过一个测试，打开WAL压缩。只不过打开WAL压缩后，PG数据块的高并发写入性能并未提升，反而略有下降。能够从以前的PG 12的WAL压缩中获得性能提升的场景十分有限。

PG 15的WAL压缩有了一个十分令人兴奋的改进，除了支持PGLZ外，WAL压缩还支持LZ4和ZSTANDARD两种压缩算法。

从官方的对比来看，ZSTD是一种平衡了压缩解压吞吐量与压缩比的十分优秀的压缩算法，而LZ在压缩比上虽然不如ZSTD，但是在压缩吞吐量上有着特别优秀的表现。这两种压缩算法的引入，必定会大大改善WAL压缩的性能。

因为时间关系，我们目前还没有全面开展PG 15的测试，我想还是等正式版出来后再做完整的测试。不过从目前国外一些朋友对PG 15的测试来看，还是十分令人期待的。我们根据Mark Callaghan的测试用例来看一看效果吧。

和我们的预期相同，使用以前的pglz，对于仅有PK的场景影响并不大，对于PG来说，第一次数据写入，都是创建的新块，不同的算法之间的影响还不算太大。但是对于其他场景影响较大。而使用LZ4的效果极佳，装载性能有了明显的提升。zstd在有多个索引时的数据装载表现出了较好的性能。

不过从上面的测试来看，还是比较简单的，因此这个测试结果页并不说明太多的问题。不过有一点是可以确定的，那就是LZ4和ZSTD的引入，会大大优化WAL 压缩的性能，从而缓解FULL PAGE WRITE的问题，也可以大大减轻DBA优化CHECKPOINT的工作。CHECKPOINT的优化可能会在大多数场景下变得更简单了，我们只要根据自己的场景需求，选择设置WAL压缩参数就可以了。

挺巧的是，在PG 15里，增加了一个新的权限:pg_checkpointer。以往checkpint命令只能由超级用户来执行。而PG 15里，只要是授予这个权限的用户，都可以在自己的应用里执行checkpoint命令了。将checkpoint命令的权限下放，是PG 15细粒度权限控制优化的一部分。不过既然敢下放权限，那就说明checkpoint带来的副作用已经可控了。随着现代硬件的发展，IO问题已经得到了大大地缓解，同时因为WAL压缩的优化，也为checkpoint权限下放提供了有力的支撑。

不过业务场景十分复杂，这个权限还是不要随便授予，因为目前来看，我还没有想清楚，这个权限下放的真实好处在什么地方，什么场景下，应用需要自己去控制checkpoint。如果有一天，DBA发现一个挠头的IO性能问题，是因为某个应用系统频繁执行checkpoint引发的，那就麻烦大了。对于开发人员来说，让每条记录尽快写盘肯定是件喜闻乐见的事情，而对于DBA来说，那可能是个灾难。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。