Horton

Re: Configuring synchronous replication

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

View thread
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Csaba Nagy <ncslists@googlemail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, jd@commandprompt.com, Thom Brown <thom@linux.com>, Bruce Momjian <bruce@momjian.us>, Andrew Dunstan <andrew@dunslane.net>, Dave Page <dpage@pgadmin.org>, Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>, Fujii Masao <masao.fujii@gmail.com>, Josh Berkus <josh@agliodbs.com>, pgsql-hackers@postgresql.org
Date: 2010-09-23T13:18:37Z
Lists: pgsql-hackers 
On 23/09/10 15:26, Csaba Nagy wrote:
> Unfortunately it was quite long time ago we last tried, and I don't
> remember exactly what was bottlenecked. Our application is quite
> write-intensive, the ratio of writes to reads which actually reaches the
> disk is about 50-200% (according to the disk stats - yes, sometimes we
> write more to the disk than we read, probably due to the relatively
> large RAM installed). If I remember correctly, the standby was about the
> same regarding IO/CPU power as the master, but it was not able to
> process the WAL files as fast as they were coming in, which excludes at
> least the network as a bottleneck. What I actually suppose happens is
> that the one single process applying the WAL on the slave is not able to
> match the full IO the master is able to do with all it's processors.

There's a program called pg_readahead somewhere on pgfoundry by NTT that 
will help if it's the single-threadedness of I/O. Before handing the WAL 
file to the server, it scans it through and calls posix_fadvise for all 
the blocks that it touches. When the server then replays it, the data 
blocks are already being fetched by the OS, using the whole RAID array.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com