On Monday 11 April 2005 10:16, Marc G. Fournier wrote:
> On Mon, 11 Apr 2005, Darcy Buskermolen wrote:
> > 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.
>
> 'k, if I'm reading the diagram properly, you are doing cascading
> subscribers?  dbitech -> arch/sparc ... sparc -> freebsd/aix ... freebsd
> -> delenn/bestestpuppy/darcy-2000?


That is correct.

>
> ----
> Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
> Email: scrappy at hub.org           Yahoo!: yscrappy              ICQ: 7615664
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general

-- 
Darcy Buskermolen
Wavefire Technologies Corp.

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