Re: rapid degradation after postmaster restart - Mailing list pgsql-performance

From Matthew T. O'Connor
Subject Re: rapid degradation after postmaster restart
Date
Msg-id 4058BBA5.4080002@zeut.net
Whole thread Raw
In response to Re: rapid degradation after postmaster restart  (Andrew Sullivan <ajs@crankycanuck.ca>)
List pgsql-performance
Andrew Sullivan wrote:

>The vacuum delay stuff that you're working on may help, but I can't
>really believe it's your salvation if this is happening after only a
>few minutes.  No matter how much you're doing inside those functions,
>you surely can't be causing so many dead tuples that a vacuum is
>necessary that soon.  Did you try not vacuuming for a little while to
>see if it helps?
>
>

Some of this thread was taken off line so I'm not sure it was mentioned
on the list, but a big part of the problem was that Joe was running into
the same bug that Cott Lang ran into a while ago which caused the vacuum
threshold to get set far too low resulting in vacuums far too often..
This has been fixed and the patch has been committed unfortunately it
didn't make it into 7.4.2, but it will be in 7.4.3 / 7.5.

>I didn't see it anywhere in this thread, but are you quite sure that
>you're not swapping?  Note that vmstat on multiprocessor Solaris
>machines is not notoriously useful.  You may want to have a look at
>what the example stuff in the SE Toolkit tells you, or what you get
>from sar.  I believe you have to use a special kernel setting on
>Solaris to mark shared memory as being ineligible for swap.
>
>

I haven't heard from Joe how things are going with the fixed
pg_autovacuum but that in combination with the vacuum delay stuff should
work well.

Matthew




pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: atrocious update performance
Next
From: Seum-Lim Gan
Date:
Subject: PostgreSQL Disk Usage and Page Size