On Monday 11 April 2005 09:06, Hannu Krosing wrote:
> On E, 2005-04-11 at 09:19 -0400, cbbrowne at ca.afilias.info wrote:
> > > Does anyone have any #s on how fast Slony works?
> > >
> > > On all my current uses, there aren't a heavy number of
> > > 'insert/update/delete's happening, so of course, it never falls behind
> > > ...
> > >
> > > If one were to have a 'write master' with a bunch of 'read
> > > subscribers', I imagine there is a point where the writes to the
> > > subscribers would start to get delayed, right?  Has anyone hit such a
> > > limit?
> >
> > I haven't seen that limit; I would expect it to be surprisingly high, and
> > I know of a useful workaround.
>
> ...
>
> > Furthermore, all the rest being said, it's pretty easy to get Slony-I to
> > "bog down;" you just need to do heavy updates that get applied "en
> > masse". As with:
> >
> >   update some_replicated_table set updated_on = now() where id in
> >      (select id from some_replicated_table limit 5000);
> >
> > That one query creates 5000 updates, which, from Slony-I's perspective,
> > are 5000 _individual_ updates.  5000 entries in sl_log_1, and such.
>
> another way to easily bog down Slony is to have some really long
> transactions, which prevent some significant tables from being cleaned
> up by vacuum. The most relevant of these is pg_listener, which has no
> index on it, so having a 24-hour query (either VACUUM, COPY (from
> slony's subscribe or other), all commands from single run of pg_dump, or
> just an open psql connection after begin; + some queries) can grow
> pg_listener big enough to make any event propagation take tens of
> seconds and causing replication to fall behind significantly.

I quite often test slony with the following logical layout
http://www.dbitech.ca/slony/slony-testing.png  All DB's are running on 1 
PostgreSQL cluster, using the basic pgbench to generate load.

Replication  from dbitech(1) to arch(2) sparc(3) freensd5(4) shows a typical 
30 second replication delay...   dbitech(1) to parisc(12) on the other hand, 
I see them being upwards of 20 minutes behind.  When i get some more time 
I'll see what i can do about plotting this stuff out.


-- 
Darcy Buskermolen
Wavefire Technologies Corp.

http://www.wavefire.com
ph: 250.717.0200
fx: 250.763.1759