I've now backed off to version 7.4.1, which doesn't exhibit the problems that
8.0.3 does. I guess I'll wait 'till the next version and see if any progress
has occurred.
Rob
When grilled further on (Tue, 19 Jul 2005 22:49:08 -0600),
Robert Creager <[EMAIL PROTECTED]> confessed:
> When grilled f
When grilled further on (Tue, 19 Jul 2005 12:09:51 -0600),
Robert Creager <[EMAIL PROTECTED]> confessed:
> 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 t
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:
> Tom Lane <[EMAIL PROTECTED]> confessed:
>> It's still far from clear what's going on there, but it might be
>> interesting to see if turning off the vacuum delay changes your results
>> with 8.0.
> Can that be affected by hupping the server, or do I nee
When grilled further on (Mon, 18 Jul 2005 09:23:11 -0400),
Tom Lane <[EMAIL PROTECTED]> confessed:
> It's still far from clear what's going on there, but it might be
> interesting to see if turning off the vacuum delay changes your results
> with 8.0.
>
Can that be affected by hupping the server
When grilled further on (Mon, 18 Jul 2005 00:10:53 -0400),
Tom Lane <[EMAIL PROTECTED]> confessed:
> 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 in 7.4?
Robert Creager <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> confessed:
>> 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 in 7.4?
> I've "vac
When grilled further on (Sun, 17 Jul 2005 23:43:29 -0600),
Robert Creager <[EMAIL PROTECTED]> confessed:
> I've 6 runs going concurrently. Just saw (vmstat 1) a set of 8 seconds where
> the CS didn't drop below 90k, but right now its at ~300 for over 30 seconds...
> It's bouncing all over the pl
When grilled further on (Mon, 18 Jul 2005 00:10:53 -0400),
Tom Lane <[EMAIL PROTECTED]> confessed:
> 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 in 7.4?
When grilled further on (Mon, 18 Jul 2005 00:18:30 -0400),
Tom Lane <[EMAIL PROTECTED]> confessed:
> Robert Creager <[EMAIL PROTECTED]> writes:
> > I am, and it is. It's ANALYZING and VACUUM'ing tables every interval (5 mi=
> > nutes
> > - 8.0.3). Right now, for that last 4 hours, I'm not VACUUM
When grilled further on (Sun, 17 Jul 2005 22:09:11 -0700),
"Jeffrey W. Baker" <[EMAIL PROTECTED]> confessed:
>
> Did you build 8.0.3 yourself, or install it from packages? I've seen in
> the past where pg would build with the wrong kind of mutexes on some
> machines, and that would send the CS t
When grilled further on (Mon, 18 Jul 2005 00:10:53 -0400),
Tom Lane <[EMAIL PROTECTED]> confessed:
> Have you tried reverting
> to the cron-based vacuuming method you used in 7.4?
>
I just stopped autovacuum, ran a manual vacuum analyze on 803 (2064 pages
needed, 800 FSM setting) and re-star
When grilled further on (Mon, 18 Jul 2005 16:17:54 +1200),
David Mitchell <[EMAIL PROTECTED]> confessed:
> Maybe you should check who is holding locks.
Hmmm... The only difference is how the vacuum is run. One by autovacuum, one
by cron (vacuum analyze every 5 minutes).
Cheers,
Rob
--
23:01
When grilled further on (Mon, 18 Jul 2005 00:18:43 -0400),
"Matthew T. O'Connor" confessed:
> Have you turned on the query logging to see what queries are
> taking so long?
>
Yeah. In the original message is a typical query. One from 741 and the other
on 803. On 803, an explain analyze is d
Robert Creager <[EMAIL PROTECTED]> writes:
> I am, and it is. It's ANALYZING and VACUUM'ing tables every interval (5 mi=
> nutes
> - 8.0.3). Right now, for that last 4 hours, I'm not VACUUMing the 7.4.1
> database and it's still clicking along at < .2 second queries.
Have you compared physical t
I am, and it is. It's ANALYZING and VACUUM'ing tables every interval (5 minutes
- 8.0.3). Right now, for that last 4 hours, I'm not VACUUMing the 7.4.1
database and it's still clicking along at < .2 second queries. Last year
(7.4.1), I noticed that it took about a week of heavy activity (for th
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
23 matches
Mail list logo
