Simon Riggs wrote:
Aside from a bunch of customized pgbench benchmarks (on the 9.6 GB sample database we use), which are "better than nothing, but far from the best", not really. In my experience, the larger the database; slower the commit rate; and less frequently the checkpoints - the better the performance of synchronous warm-replication. In our tests, higher commit rates and more frequent checkpoints incur a higher penalty. Basically, the more WAL activity the higher the cost.On Mon, 2007-06-04 at 10:21 -0400, Chander Ganesan wrote:It's not too hard to put together a "warm standby" synchronous replication mechanism with overhead that isn't too much more than what you incur by enabling PITR... Such systems can also have very fast failover on failure detection (via heartbeat2), and be synchronous.Do you have any performance measurements of either the replication overhead or the failover time? I'm interested in how well we cope with high transaction rates. Thanks. If I have time I'll see if we can run a more meaningful metric (need to generate a smaller database for that) the next time we have a performance tuning class (in August). The failover time is tunable to some extent...via heartbeat2 (incurs < 1% performance penalty, but with sub-second failover this can go up a bit), and can be pretty quick (I usually set it up with around a 3 second failover time on node failure, then factor that in with the amount of time required for WAL auto-recovery)...it really depends a lot on what your metric is for "failure" (since node failover is probably the "worst worst case"). -- Chander Ganesan The Open Technology Group One Copley Parkway, Suite 210 Morrisville, NC 27560 Phone: 877-258-8987/919-463-0999 http://www.otg-nc.com |