关于PostgreSQL的full_page_writes

前言

full_page_writes用于防范宕机时数据的部分写入导致无法恢复的问题，还有一个好处是加速replay速度，可以避免随机读。但是，full_page_writes对性能的影响也非常大。 和关闭full_page_writes相比，打开full_page_writes可能会使TPS减少30%以上，产生的WAL数据量可能会达到5倍以上。同一个page上的更新越稀疏问题越严重。

如何优化

1. 关闭full_page_writes

   如果硬件可以减少部分页面写入的风险，或文件系统支持原子写，或者在发生故障时打算用备份恢复，可以考虑将其关闭。

   什么文件系统支持原子写呢？很多技术文章的都以ZFS举例。但Linux下常用的ext4也可以通过设置“data=journal”使其支持事务写入。下面有篇文章，用ext4的“data=journal”取代MySQL的double write buffer，性能提升了55%（但这个数据应该严重依赖测试场景的，因为很多其他人的测试结果表明，即使关闭double write buffer性能也只有10%左右的提升）。

   https://www.percona.com/blog/2014/05/23/improve-innodb-performance-write-bound-loads/

2. 启用WAL压缩

   9.5提供了WAL压缩功能，通过设置wal_compression=on可以启用压缩。根据作者在patch里提供的数据，tps提升20%和WAL数据减小到原来的1/3（当然效果和测试场景有关）。具体参考下面

   http://blog.163.com/digoal@126/blog/static/163877040201381963422198/

3. 修改PG防部分写的机制

   康贤在博客中提到一个double write的patch用于取代full_page_writes，其实就是把MySQL的double write的逻辑搬过来（MySQL的double write比PG的full_page_writes对性能的影响小，并且不会使日志文件膨胀）。我没找这个patch的出处，不知道效果和社区的意见如何。

Oracle怎么解决这个问题的？

找到下面这篇不错的文章(其实是讲MySQL doublewrite的)，答案令人吃惊。Oracle对部分页面写根本不设防，出了事从备份恢复。我想Oracle能这么做也许还因为Oracle客户的系统大多跑在不错的硬件上，部分页面写发生的概率比较低。照这个思路，其实PG或MySQL的很多系统也完全可以关闭对部分页面写防护，出了故障还有HA还有备份。

http://www.cnblogs.com/cchust/p/3961260.html