Re: VACUUMs take twice as long across all nodes

From: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
To: Gavin Hamill <gdh(at)laterooms(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: VACUUMs take twice as long across all nodes
Date: 2006-10-26 21:59:36
Message-ID: 20061026215936.GO26892@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Thu, Oct 26, 2006 at 09:35:56PM +0100, Gavin Hamill wrote:
> On Thu, 26 Oct 2006 14:17:29 -0500
> "Jim C. Nasby" <jim(at)nasby(dot)net> wrote:
>
> > Are you sure that there's nothing else happening on the machine that
> > could affect the vacuum times? Like, say a backup? Or perhaps updates
> > coming in from Slony that didn't used to be there?
>
> I'm absolutely certain. The backups run from only one slave, given that
> it is a full copy of node 1. Our overnight traffic has not increased
> any, and the nightly backups show that the overall size of the DB has
> not increased more than usual growth.
>
> Plus, I have fairly verbose logging, and it's not showing anything out
> of the ordinary.
>
> Like I said, it's one of those awful hypothesis/hand-waving problems :)

Well, the fact that it's happening on all your nodes leads me to think
Slony is somehow involved. Perhaps it suddenly decided to change how
often it's issuing syncs? I know it issues vacuums as well, so maybe
that's got something to do with it... (though I'm guessing you've
already looked in pg_stat_activity/logs to see if anything
correlates...) Still, it might be worth asking about this on the slony
list...
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message George Pavlov 2006-10-26 22:03:38 Re: query slows down drastically with increased number of fields
Previous Message Tom Lane 2006-10-26 21:53:10 Re: query slows down drastically with increased number of fields