Re: [OT] Slony Triggers pulling down performance?

From: Ow Mun Heng <Ow(dot)Mun(dot)Heng(at)wdc(dot)com>
To: Chris Browne <cbbrowne(at)acm(dot)org>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: [OT] Slony Triggers pulling down performance?
Date: 2008-01-28 03:16:11
Message-ID: 1201490171.5854.10.camel@neuromancer.home.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


On Fri, 2008-01-18 at 14:57 -0500, Chris Browne wrote:
> Ow(dot)Mun(dot)Heng(at)wdc(dot)com (Ow Mun Heng) writes:
> > Just wondering if my 'Perceived' feeling that since implementing slony
> > for master/slave replication of select tables, my master database
> > performance is getting slower.
> >
> > I'm constantly seeing a very high amount of IO wait. ~40-80 according to
> > vmstat 1
> >
> > and according to atop. (hdb/hdc = raid1 mirror)
> > DSK | hdb | busy 83% | read 1052 | write 50 | avio 7 ms |
> > DSK | hdc | busy 81% | read 1248 | write 49 | avio 6 ms |
>
> The triggers generate some extra I/O, as they go off and write tuples
> into sl_log_1/sl_log_2, so there's certainly a cost, there.
>
> When you pull data from sl_log_1/sl_log_2, that will have a cost, too.
>
> Replication does not come at zero cost...

I've been battling with this issus for the past week and that prompted a
few changes in the manner I pull the data and in the location where i
store the data. I ended up implementing partitioning on the 2 main
largest (problematic) tables and put it intp weekly rotation and moved
the broke the 3 disk raid1(1 spare) spare disk and used that as the
slony-I sl_log_1/sl_log_2 tablespace.

Now, everything is back to normal. (until I break it again!!) IO Wait is
hovering between 0-40%

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Merlin Moncure 2008-01-28 03:59:28 Re: what is it that \d actually does
Previous Message Jaime Casanova 2008-01-28 02:40:56 Re: match accented chars with ASCII-normalised version