聊聊PG double buffering的优化

谈了PG的Double Buffering，这一点是很多诟病PG的人经常提到的问题。不过昨天老白也说了，Double Buffering其实也不是什么太大的问题，对于绝大多数PG数据库系统来说，这个问题的负面影响绝对没有网上的那些文章​说的那么玄乎，甚至对于绝大多数数据库来说，这个问题我们可以​忽略。不过对于一些超大型的PG数据库，比如从Oracle迁移到PG的大型或者超大型数据库来说，​我们还是需要做一定的优化工作的。虽然采用buffered io的数据库在DB CACHE的优化上比绕过缓冲区直接读写文件要复杂一些，但是这个问题并不是不可解决的。通过对操作系统与数据库参数的一系列优化，我们也可以让PG数据库充分享受BUFFERED IO的好处，规避Double Buffering的缺点。

第一点是确保有足够的内存，对于采用Buffered IO的数据库系统来说，越大的内存拥有越大的FILE CACHE和DB CACHE，肯定对数据库的性能有所帮助。在X86时代，内存已经不少昂贵的硬件了，因此在配置PG服务器的时候，不要为了省几个内存的钱而让自己今后的运维陷入左右为难的境地是比较明智的选择。除了配置较大内存的数据库服务器硬件之外，关闭NUMA是我们要做的第一件事情。关闭NUMA，不用管远程内存本地内存的成本开销问题，因为远程内存再慢也比硬盘快得多。在服务器与操作系统层面均关闭NUMA，可以让物理内存被均匀的使用，不会因为一个NODE上分配内存过大而导致在物理内存尚有很多空闲的时候，出现不必要的换页。对于这个问题，以前老白发过的一篇文章《Postgresql和NUMA》可以参考。

第二是大页的设置，一定要让shared buffers使用大页，对于大型PG数据库来说，这一点十分关键，如果不使用大页，有数千会话的数据库系统的页表将消耗大量的内存和CPU资源。在使用大页的时候一定要注意，不要使用透明大页。

第三是优化OS的VM相关参数。vm.swappiness参数可以设置为0.min_free_kbytes要设置为一个合理的值，不要让file cache超量使用物理内存，让OS存在出现大规模换页的风险。

第四是针对DB CACHE的脏块写入进行OS方面的优化，对于较大规模的shared buffers，其脏块刷新的每个批次的数量会有所增加，使用buffered io的系统的脏块是先写到FILE CACH中的，针对FILE CACHE脏数据后台落盘的优化决定了数据库系统是否能够平稳运行，消除写盘高峰。前两天老白写过一篇《从swappiness说起，谈谈PG的OS参数优化》，里面对这方面的优化调整有了十分明细的描述，这里我们就不再重复了。通过对文件系统脏数据写入以及存储设备的一些参数的调整，就可以优化PG数据库的这方面的问题。

第五就是shared buffers的设置策略了，我们可以不按照PG官方文档上的要求去限制shared buffers不超过OS物理内存的25%，而是可以根据我们应用系统数据的特点来设置足够打的数据库缓冲区。只要我们给会话、FILE CACHE留下足够大的内存就可以了。

第六是WAL和CHECKPOINT的设置，更大的SHARED BUFFERS需要更强大的WAL和CHECKPINT的支持，PG的缺省配置只能适合于特别小的数据库系统，这方面的优化技巧老白以前发过多篇文章，大家可以参考。《《PG的检查点与检查点优化》、《从pg_stat_bgwriter中能看到些什么？》、《聊聊PG的FULL_PAGE_WRITES》、《数据库脏块写入与WRITE AHEAD LOG》。

第七是正确的设置IO评估类的参数，这些参数对于PG的执行计划评估十分重要。前些天老白也曾经写过《IO评估类参数对SQL执行计划的影响》，里面讨论了相关的IO评估类参数的问题，大家可以参考。

似乎看上去很复杂，我只是列出了一些主要的针对Double Buffering的优化要点，还有一些细小的方面今天因为篇幅关系无法展开讨论。不过实际上这些优化方案，大多数针对不存在Double Buffering的数据库也是需要关注的，因此实际上来说优化并不复杂。只要根据业务系统的特点，平衡好DB CACHE与FILE CACHE，让OS不产生严重换页，数据库系统就能够稳定高性能的运行了。当然配置足够的物理内存，会让运维与优化更为简单一些。花上万把块钱能够解决的事情，肯定比花几十万去优化划算的多，不过这笔帐有时候我们的领导还真不一定算得清，DBA在必要的时候还是要提醒一下的。

作者：白鳝