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
On Sun, 2005-07-17 at 21:34 -0600, Robert Creager wrote:
> 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
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
Ok, it doesn't look like an autovacuum problem. The only other thing I
can think of is that some query is doing a seq scan rather than an index
scan. Have you turned on the query logging to see what queries are
taking so long?
Matt
Robert Creager wrote:
I am, and it is. It's ANALYZING a
Sounds like either someone is holding a lock on your pg8 db, or maybe
you need a vacuum full. No amount of normal vacuuming will fix a table
that needs a vacuum full. Although if that were the case I'd expect you
to have slow queries regardless of the number of concurrent connections.
Maybe you
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
Robert Creager wrote:
For 8.03, pg_autovacuum is running. On 7.4.1, I set up a cron job to vacuum
analyze every 5 minutes.
Are you sure that pg_autovacuum is doing it's job? Meaning are you sure
it's vacuuming as often as needed? Try to run it with -d2 or so and
make sure that it is ac
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
Christopher Petrilli <[EMAIL PROTECTED]> writes:
> I have a unique scenerio. My DB is under "continual load", meaning
> that I am constantly using COPY to insert new data into the DB. There
> is no "quiet period" for the database, at least not for hours on end.
> Normally, checkpoint_segments ca
I have a unique scenerio. My DB is under "continual load", meaning
that I am constantly using COPY to insert new data into the DB. There
is no "quiet period" for the database, at least not for hours on end.
Normally, checkpoint_segments can help absorb some of that, but my
experience is that if
17 matches
Mail list logo
