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
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
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
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
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
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
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
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
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
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
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: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
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 (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: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 (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 (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
17 matches
Mail list logo
