Re: Configuring synchronous replication

Simon Riggs <simon@2ndquadrant.com>

From: Simon Riggs <simon@2ndQuadrant.com>

To: Csaba Nagy <ncslists@googlemail.com>

Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, 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-24T07:19:24Z

Lists: pgsql-hackers

On Thu, 2010-09-23 at 14:26 +0200, 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.
> 
> If you're interested, I could try to set up another try, but it would
> be on 8.3.7 (that's what we still run). On 9.x would be also
> interesting...

Substantial performance improvements came in 8.4 with bgwriter running
in recovery. That meant that the startup process didn't need to spend
time doing restartpoints and could apply changes continuously.

-- 
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Development, 24x7 Support, Training and Services