Ok, I was able to run a vacuumdb -f -v on my largest db over the weekend.
However, I am having trouble reading the results of the table portion. Here
area a couple of tables, what should I be looking at. First table is the key
table to the db, and the second is the largest table in the db.
"Chris Hoover" <[EMAIL PROTECTED]> writes:
> Here is the postgresql.conf from the server with the 11GB db:
> max_fsm_pages = 1 # min 1000, fsm is free space map, ~6 bytes
It's unlikely that that's enough for an 11Gb database, especially if
you're only vacuuming a few times a week. Yo
Chris Hoover wrote:
On Friday 23 April 2004 14:57, Ron St-Pierre wrote:
Does this apply to 7.3.4 also?
No it doesn't, I didn't look back through the thread far enough to see
what you were running. I tried it on 7.3.4 and none of the summary info
listed below was returned. FWIW one of our DBs wa
On Fri, 23 Apr 2004, Chris Hoover wrote:
> On Friday 23 April 2004 13:21, scott.marlowe wrote:
> > On Fri, 23 Apr 2004, Chris Hoover wrote:
> > > DB's on Powervaults 220S using raid 5 (over 6 disks)
> >
> > What controller is this, the adaptec? We've found it to be slower than
> > the LSI megarai
On Friday 23 April 2004 14:57, Ron St-Pierre wrote:
Does this apply to 7.3.4 also?
> Actually, since he's running 7.4, there's an even better way. Do a
> "VACUUM VERBOSE" (full-database vacuum --- doesn't matter whether you
> ANALYZE or not). At the end of the very voluminous output, you'll se
Josh Berkus wrote:
Chris,
Sorry for the confusion here. I can't run any sort of vacuum durin the day
due to performance hits. However, I have run vacuums at night. Several
nights a week I run a vacuumdb -f -z on all of the clusters. I can take
serveral hours to complete, but it does compl
Chris,
> Sorry for the confusion here. I can't run any sort of vacuum durin the day
> due to performance hits. However, I have run vacuums at night. Several
> nights a week I run a vacuumdb -f -z on all of the clusters. I can take
> serveral hours to complete, but it does complete.
Well, her
On Friday 23 April 2004 13:21, scott.marlowe wrote:
> On Fri, 23 Apr 2004, Chris Hoover wrote:
> > DB's on Powervaults 220S using raid 5 (over 6 disks)
>
> What controller is this, the adaptec? We've found it to be slower than
> the LSI megaraid based controller, but YMMV.
>
We are using the perc3
Sorry for the confusion here. I can't run any sort of vacuum durin the day
due to performance hits. However, I have run vacuums at night. Several
nights a week I run a vacuumdb -f -z on all of the clusters. I can take
serveral hours to complete, but it does complete.
During the day, I have
I know the numbers look ok, but we are definetly suffering. Also, if I try to
run any sort of vacuum or other db activity during normal business hours,
load goes through the roof. I have seen loads of over 10 when trying to
vacuum the larger cluster and would have to kill the vacuums due to
c
On Fri, 23 Apr 2004, Chris Hoover wrote:
> DB's on Powervaults 220S using raid 5 (over 6 disks)
What controller is this, the adaptec? We've found it to be slower than
the LSI megaraid based controller, but YMMV.
> Running RH ES 2.1
Are you running the latest kernel for ES 2.1? Early 2.4 kern
Chris,
> I need some help. I have 5 db servers running our database servers, and
> they all are having various degrees of performance problems. The problems
> we are experiencing are:
I'mm confused. You're saying "general slowness" but say that most queries run
in under .01 seconds. And you
- Original Message -
From: "Chris Hoover" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, April 23, 2004 9:31 AM
Subject: [PERFORM] Help with performance problems
I need some help. I have 5 db servers running our database serv
I need some help. I have 5 db servers running our database servers, and they
all are having various degrees of performance problems. The problems we are
experiencing are:
1. General slowness
2. High loads
All of our db's are running on Dell Poweredge 2650 with 2 P4 Xeons (2.8 ->
3.06 GHz)
14 matches
Mail list logo
