On Tue, 19 Jul 2005 12:54:22 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Robert Creager <[EMAIL PROTECTED]> writes:
>
> Hmm, I hadn't thought about the possible impact of multiple concurrent
> vacuums. Is the problem caused by that, or has performance already gone
> into the tank by the time the
On Tue, 19 Jul 2005 12:54:22 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Hmm, I hadn't thought about the possible impact of multiple concurrent
> vacuums. Is the problem caused by that, or has performance already gone
> into the tank by the time the cron-driven vacuums are taking long enough
> to
Robert Creager <[EMAIL PROTECTED]> writes:
> Alright. Restarted the 803 database. Cron based vacuum analyze is
> running every 5 minutes. vacuum_cost_delay is 0. The problem showed
> up after about 1/2 hour of running. I've got vacuum jobs stacked from
> the last 35 minutes, with 2 vacuums run
On Mon, 18 Jul 2005 13:52:53 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Start a fresh psql session and "SHOW vacuum_cost_delay" to verify what
> the active setting is.
>
Alright. Restarted the 803 database. Cron based vacuum analyze is running
every 5 minutes. vacuum_cost_delay is 0. The
In regards to
http://archives.postgresql.org/pgsql-performance/2005-07/msg00261.php
Tom Says:
> ... as indeed it does according to Robert's recent reports. Still
> awaiting the definitive test, but I'm starting to think this is another
> case of the strange behavior Ian Westmacott exhibited.
Ok
Robert Creager <[EMAIL PROTECTED]> writes:
> Around 8:15 I was starting to receive hits of a few seconds of high CS hits,
> higher than the previous 7 hour run on 741. I changed the vacuum delay to 0
> and
> HUP'ed the server (how can I see the value vacuum_cost_delay run
> time?).
Start a fresh
On Mon, 18 Jul 2005 13:52:53 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Start a fresh psql session and "SHOW vacuum_cost_delay" to verify what
> the active setting is.
Thanks. It does show 0 for 803 in a session that was up since I thought I had
HUPed the server with the new value.
This is lea
Robert Creager <[EMAIL PROTECTED]> writes:
> I'm guessing this is the CS problem that reared it's head last year?
The context swap problem was no worse in 8.0 than in prior versions,
so that hardly seems like a good explanation. Have you tried reverting
to the cron-based vacuuming method you used
Sigh...
I recently upgraded from 7.4.1 to 8.0.3. The application did not change. I'm
now running both database concurrently (on different ports, same machine) just
so I could verify the problem really exists.
The application is a custom test application for testing mechanical systems.
The run
