Hi,

At 07:37 23/05/2008, Stephane LAPIE wrote:
>Replication basically occurs fine, to the exception that the 
>European servers accumulate lag for around two, three hours (six in 
>worst cases observed) when data processing occurs in Asia. We tried 
>raising "sync_group_maxsize" in every slon.conf to 24, which 
>diminished the number of events replication was lagging behind, but 
>did not diminish the lag time (Both are observed through the 
>_SCHEMA.sl_status view, and made into a graph through MRTG)

You might want to bump up sync_group_maxsize to a much higher value 
(we have it set to 1000, with desired_sync_time set to 0, on some 
boxes), that can help quite a bit when the slave is lagging a bit too 
much. That will allow slon to get more data from each cursor, so you 
save on cursor preparation time, and it should also cope a little bit 
better with the "high" network latency.

Also remember that Slony does not really like long transactions, so 
make sure you don't keep transactions open for too long for no good 
reason. But if that were the issue you would probably have the same 
problem for "local" replication.

>By reducing processed data quantities of 30%, we could reduce the 
>lag time by half. We also checked the VPN status, and there is no 
>obvious anomaly nor QoS. The only startling point would be that 
>bandwidth usage is extremely low, and that reducing processed data 
>quantities did not make the bandwidth usage fall any lower.
>
>It looks as though as Slony is actually limiting itself to not 
>over-use the network's bandwidth, but actually ends up using nearly 
>nothing. Given our current network environment, we could perfectly 
>cope with Slony using 10 times more bandwidth with no problem.

I think it's more of a latency issue that anything. Having 300 ms 
instead of a few ms on each roundtrip can make quite a difference 
when you have lots of roundtrips, so the idea is to reduce the number 
of roundtrips as much as possible. This includes having local slons 
(already the case), maximizing the number of events handled on each 
loop (sync_group_maxsize), maximizing the number of log items 
processed on each fetch (as advised by Christopher).

Jacques.