Re: rapid degradation after postmaster restart

From: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
To: Andrew Sullivan <ajs(at)crankycanuck(dot)ca>
Cc: pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: rapid degradation after postmaster restart
Date: 2004-03-17 20:57:09
Message-ID: 4058BBA5.4080002@zeut.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-03-17 21:00:34 list.c (was Re: Doxygen?)
Previous Message Marc G. Fournier 2004-03-17 20:47:15 Re: pgFoundry WAS: On pgweb project

Browse pgsql-performance by date

  From Date Subject
Next Message Seum-Lim Gan 2004-03-17 23:52:13 PostgreSQL Disk Usage and Page Size
Previous Message Tom Lane 2004-03-17 20:52:02 Re: atrocious update performance