"Henry" <henry at zen.co.za> writes:
> On Fri, May 23, 2008 1:09 pm, Hannu Krosing wrote:
>> On Fri, 2008-05-23 at 19:57 +0900, Stephane LAPIE wrote:
>> I have not been running slony for quite a long time. I last used it at
>> Skype a few years ago before we moved to our own implementation -
>> Londiste/pgQ from SkyTools. The main reason was that our cluster got too
>> big to manage with slony.
>
> Sadly, the documentation for SkyTools is *appalling*.  I took a look some
> time ago and ran away pronto.
>
> I think the origional question still stands:  how do you get slony to pump
> more data and take full advantage of available network bandwidth.  In our
> case, we have a large cluster with gigabit networking, yet usage is a
> paltry few megabits/s (so large updates take hours to days to replicate).
>
> I recall asking the same question some months ago, but no real solution
> surfaced.  It appears to be pretty much a case of "that's the way slony
> works."

The recommendation to run the slon near the node it is managing was a
good one; that will cut down on the round-tripping between slon and
local node.

The other thing that comes to mind is that maybe increasing the number
of rows fetched by the cursor from the provider would be of some help.
Default value for SLON_FETCH_DATA_SIZE is 100, which means it's
FETCHing 100 rows from the cursor each time; there may be value in
increasing that somewhat.

The other thing to do is to try to see what your cluster is busy with.
Looking at pg_stat_activity on both the provider and the subscriber
should give an idea of where the bottleneck is; one of them is likely
to consistently be IDLE, and that should tell us what to look at.

I'm not sure but that maybe something's flakey with your network; that
would also be an explanation for the problem, and Slony-I can't
resolve that!
-- 
output = ("cbbrowne" "@" "linuxdatabases.info")
http://cbbrowne.com/info/x.html
"I would rather spend 10 hours reading someone else's source code than
10  minutes listening  to Musak  waiting for  technical  support which
isn't." -- Dr. Greg Wettstein, Roger Maris Cancer Center