From: | "jody brownell" <jody(dot)brownell(at)q1labs(dot)com> |
---|---|
To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
Cc: | "Csaba Nagy" <nagy(at)ecircle-ag(dot)com>, "postgres performance list" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Help tuning autovacuum - seeing lots of relationbloat |
Date: | 2006-06-21 23:08:55 |
Message-ID: | 200606212008.56137.jody.brownell@q1labs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Well, for one we did introduce a TX leak which was preventing autovac from running. I guess that was _the_ issue.
I have since fixed it and an now testing.... looks much better, nothing concerning....
(fingers crossed until morning :)). debug logs are full of vac/anal of the tables... so, for now I am back
on track moving forward... Now that auto vac is actually running, the box is feeling slightly more sluggish.
BTW - As soon as we deliver to QA, I will post the test case for the memory leak I was seeing the other day.
(I have not forgotten, I am just swamped)
Thanks for the help all. Much appreciated.
Cheers.
On Wednesday 21 June 2006 19:11, Jim C. Nasby wrote:
> On Wed, Jun 21, 2006 at 04:41:45PM -0300, jody brownell wrote:
> > BTW, in production with a similar load - autovacuum with default out of the box
> > settings seems to work quite well....
> >
> > I double checked this earlier today.
>
> So what's different between production and the machine with the problem?
>
> The issue with autovac is that it will only vacuum one table at a time,
> so if it's off vacuuming some other table for a long period of time it
> won't be touching this table, which will be a problem. Now, if that's
> actually what's happening...
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2006-06-22 01:19:07 | Re: Performance of DOMAINs |
Previous Message | Peter Wilson | 2006-06-21 23:08:53 | Poor performance - fixed by restart |