Question on hardware & server capacity - Mailing list pgsql-performance

From Steve Wolfe
Subject Question on hardware & server capacity
Date
Msg-id 008701c2b286$4c9c2ae0$88693fd1@WEASEL
Whole thread Raw
Responses Re: Question on hardware & server capacity
Re: Question on hardware & server capacity
List pgsql-performance
  Well, our current database server is getting tremendously loaded, and
right now there isn't a clear-cut choice as to an upgrade path - at least
not within the commodity hardware market.

  The machine is a dual AthlonMP 2000, with 2 gigs of RAM.  the loads on
the machine are getting out of hand, and performance is noticeably slowed.
'top' shows the CPU's as being anywhere from 30% to 50% idle, with (on
average) 5-10 postmasters in the "non-idle" state.  'vmstat' shows bi/bo
pegged at zero (copious quantities of disk cache, fsync turned off),
interrupts fluctuating between 200 and 1,000 per second (avg. is approx
400), context switches between 1300 and 4500 (avg. is approx 2300).  I
logged some queries, and found that in an average second, the machine
forks off 10 new backends, and responds to 50 selects and 3 updates.

  My feelings are that the machine is being swamped by both the number of
context switches and the I/O, most likely the memory bandwidth.  I'm
working on implementing some connection pooling to reduce the number of
new backends forked off, but there's not much I can do about the sheer
volume (or cost) of queries.

  Now, if quad-Hammers were here, I'd simply throw hardware at it.
Unfortunately, they're not.  So far, about the only commodity-level answer
I can think of would be a dual P4 Xeon, with the 533 MHz bus, and
dual-channel DDR memory.  That would give each processor approximately
double the memory bandwidth over what we're currently running.

  I'm fairly sure that would at least help lower the load, but I'm not
sure by how much.  If anyone has run testing under similar platforms, I'd
love to hear of the performance difference.  If this is going to chop the
loads in half, I'll do it.  If it's only going to improve it by 10% or so,
I'm not going to waste the money.

Steve


pgsql-performance by date:

Previous
From: george young
Date:
Subject: Re: preliminary testing, two very slow situations...
Next
From: Hilmar Lapp
Date:
Subject: join over 12 tables takes 3 secs to plan