如何遏制小产权房PostgreSQL WAL的疯狂增长

来源：蜘蛛抓取(WebSpider) 时间：2017-10-25 04:47 标签： 如何遏制有偿家教
随机文章分类目录
2017年十月 &(1)
2017年九月 &(2)
2017年八月 &(4)
2017年七月 &(2)
2017年六月 &(3)
2017年五月 &(4)
2017年四月 &(2)
2017年三月 &(8)
2017年二月 &(7)
2017年一月 &(6)
2016年十二月 &(10)
2016年十一月 &(13)
2016年十月 &(20)
2016年九月 &(4)
2016年八月 &(9)
2016年七月 &(2)
2016年六月 &(6)
2016年五月 &(11)
2016年三月 &(6)
2016年二月 &(3)
2015年十二月 &(2)
2015年十一月 &(4)
2015年十月 &(2)
2015年九月 &(6)
2015年七月 &(8)
2015年一月 &(5)
2014年十二月 &(3)
2014年九月 &(7)
2014年七月 &(4)
2014年六月 &(11)
2014年四月 &(2)
2014年三月 &(2)
2014年二月 &(5)
2014年一月 &(1)
2013年十二月 &(1)
2013年十一月 &(6)
2013年十月 &(1)
2013年八月 &(1)
2013年七月 &(10)
2013年六月 &(10)
2013年三月 &(1)
2012年十二月 &(1)
2012年十一月 &(2)
2012年十月 &(1)
2012年九月 &(1)
2012年七月 &(4)
2012年六月 &(5)
2012年五月 &(4)
2012年四月 &(3)
2012年三月 &(1)
2012年二月 &(4)
2012年一月 &(1)
2011年十二月 &(4)
2011年十一月 &(2)
2011年十月 &(3)
2011年九月 &(3)
2011年八月 &(2)
2011年七月 &(4)
2011年六月 &(2)
2011年五月 &(3)
2011年四月 &(3)
2011年三月 &(3)
2011年二月 &(1)
2011年一月 &(3)
2010年十二月 &(1)
2010年十一月 &(3)
2010年十月 &(4)
2010年九月 &(4)
2010年八月 &(3)
2010年七月 &(6)
2010年六月 &(1)
2010年五月 &(4)
2010年四月 &(2)
2010年三月 &(3)
2010年二月 &(1)
2010年一月 &(6)
2009年十二月 &(4)
2009年十一月 &(3)
2009年十月 &(2)
2009年九月 &(2)
2009年八月 &(2)
2009年七月 &(5)
2009年六月 &(8)
2009年五月 &(1)
2009年四月 &(5)
2009年三月 &(5)
2009年二月 &(6)
2009年一月 &(7)
2008年十二月 &(6)
2008年十一月 &(6)
2008年十月 &(3)
2008年九月 &(8)
2008年八月 &(4)
2008年七月 &(9)
2008年六月 &(9)
2008年五月 &(8)
2008年四月 &(7)
2008年三月 &(9)
2008年二月 &(3)
2008年一月 &(13)
2007年十二月 &(9)
2007年十一月 &(8)
2007年十月 &(5)
2007年九月 &(10)
2007年八月 &(12)
2007年七月 &(78)
About MeDatabase Archit@DJI
- Blogger -
- Geeker -
- ACOUG member -
Troubleshooting & Tuning
Architecture & HA Solutionpostgresql之WAL(Write Ahead Log) - 大肚熊 - 博客园
oracle中存在重做日志文件(redo log),其作用是保证数据的一致性和事务的完整性，防止在系统崩溃时最近的事务无法恢复。在postgresql中引入了WAL(write ahead log),作用相同。有不同之处的是postgresql数据库可以通过调整WAL参数控制日志写入磁盘的先后顺序。先将日志写入磁盘能够完全保证数据的完整性，在崩溃时可以恢复最近的事务；后写入磁盘，很难保证在崩溃时事务能够得到恢复，数据的结果也很难保证是真实正确的。看来了解postgresql的WAL参数是非常必要的，直接关乎到了数据库的可用性。WAL相关参数：fsync:该参数直接控制日志是否先写入磁盘。默认值是ON(先写入)。开启该值时表明，更新数据写入磁盘时系统必须等待WAL的写入完成。可以配置该参数为OFF，更新数据写入磁盘完全不用等待WAL的写入完成，没有了等待的时间，显然接下来的工作能够更早的去做，节省了时间，提高了性能。其直接隐患是无法保证在系统崩溃时最近的事务能够得到恢复，也就无法保证相关数据的真实与正确性。synchronous_commit:参数表明是否等待WAL完成后才返回给用户事务的状态信息。默认值是ON，表明必须等待WAL完成后才返回事务状态信息。配置OFF值能够更快的反馈回事务状态。因参数只是控制事务的状态反馈，因此对于数据的一致性不存在风险。但事务的状态信息影响着数据库的整个状态。该参数可以灵活的配置，对于业务没有严谨要求的事务可以配置为OFF，能够为系统的性能带来不小的提升。wal_sync_method:WAL写入磁盘的控制方式，默认值是fsync。可选用值：open_datasync,fdatasync,fsync_writethrough,fsync,open_sync。一般采用默认值即可，对于裸设备或文件系统的可选配置，在实际的使用中所带来的方便相对fsync很有限。full_page_writes:参数表明是否将整个page写入WAL。postgresql中数据处理过程中的位置只有内存和WAL中，在内存中的整个page中己包含更新提交的也包含没有提交的，如果不将整个page写入WAL中，在介质恢复的时候WAL中记录的数据不足以实现完整的恢复(说白了就是无法实现介质恢复时事务的回滚),写入整个page。说到这里似乎更明白了,postgresql中不存在类似oracle的undo文件,postgresql将前滚和回滚所需的数据都写入到了WAL。不管是否写入整个page，对数据库的PITR不影响(文档也说明了)，因为更新提交肯定要写入了WAL中。wal_buffers:用于存放WAL数据的内存空间。系统默认值是64K，执行一个大的事务肯定受到影响，应该适当的增大该参数。类似oracle中的log buffer。该参数还受以下几个参数影响。wal_writer_delay:WAL writer进程的间歇时间。默认值是200ms。准确的配置应该根据自身系统的运行状况。如果时间过长可能造成WAL buffer的内存不足；反之过小将会引起WAL的不断的写入，对磁盘的IO也是很大考验。commit_delay:表示了一个已经提交的数据在WAL buffer中存放的时间，单位ms，默认值是0，不用延迟。非0值表示可能存在多个事务的WAL同时写入磁盘。如果设置为非0，表明了某个事务执行commit后不会立即写入WAL中，而仍存放在WAL buffer中，这样对于后面的事务申请WAL buffer时非常不利，尤其是提交事务较多的高峰期，可能引起WAL buffer内存不足。如果内存足够大，可以尽量延长该参数值，能够使数据集中写入这样降低了系统的IO，提高了性能。同样如果此时崩溃数据面临着丢失的危险。个人建议采用默认值，同时将WAL文件存放在IO性能好的磁盘上。commit_siblings:该参数非常有意思，该参数还决定了commit_delay的有效性。系统默认值是5。表示当一个事务发出提交请求，此时数据库中正在执行的事务数量大于5，则该事务将等待一段时间(commit_delay的值),反之，该事务则直接写入WAL。WAL的执行控制：通过参数的介绍粗略的知道WAL实现写入的时候有1,事务commit时；2,WAL writer进程到达间歇时间时；3,checkpoint发生时；因为在数据写入数据文件之前首先要确保日志已经写入了WAL中。WAL参数调整:针对参数介绍时，说明了参数值大小时带来的性能问题。参数的配置方法并非固定，主要是根据当前系统的业务逻辑要求的严格程度，系统的更新事务负载程度，硬件的性能来决定采用何种方式对参数进行配置。
基于上述内容，欢迎大家指正，讨论。

我要回帖

更多关于 如何遏制有偿家教 的文章

 

随机推荐