[Bucardo-general] Swap replication latency

[Greg Sabino Mullane]

> However, I really am at a dead end here.  I don't know what else to try. 
> Whenever statement volume goes beyond 2-3 inserts or updates/sec 
> (average), Bucardo can't keep up.

The swap syncs in Bucardo 4 are not very optimized, but they should be 
able to keep up with that volume. You can try adjusting some of the 
'sleep' values in the config downwards to minimize how long things take.
You could also consider turning off 'ping' for the sync, and thus 
removing the NOTIFY triggers, and have the sync use checktime instead.

However, it's more likely there is some other problem - having a look 
at the log.bucardo file would be the best way for us to diagnose from 
afar, but some general tips that may apply to your situation or not:

* Keep bucardo_delta and bucardo_track small by aggressive purging 
via cron and the bucardo_purge_delta function. Same for the q table.
If they ever get big, make sure you VACUUM them as well - preferably 
VACUUM FULL then REINDEX if needed. The bucardo_delta table should 
only have thousands of rows, even on a busy server.

* The q table can be truncated if need be, and nothing will break.
Best to do it while Bucardo is stopped, however.

* Minimize the number of tables in a sync. It's better in Bucardo 4 
to have many sync with few tables rather than few syncs with many 
tables each.

* If using a pre-9 version of Postgres, make sure you are aggressively 
vacuuming the pg_listener table.

* If using a pre-8.3 version of Postgres, also vacuum the pg_class 
table aggressively (and think hard about upgrading!)

-- 
Greg Sabino Mullane greg at endpoint.com
End Point Corporation
PGP Key: 0x14964AC8
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
Url : https://mail.endcrypt.com/pipermail/bucardo-general/attachments/20110509/a2b57bea/attachment.bin