Question on hardware & server capacity

From: "Steve Wolfe" <nw(at)codon(dot)com>
To: <pgsql-performance(at)postgresql(dot)org>
Subject: Question on hardware & server capacity
Date: 2003-01-02 17:42:05
Message-ID: 008701c2b286$4c9c2ae0$88693fd1@WEASEL
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Hilmar Lapp 2003-01-02 19:42:02 join over 12 tables takes 3 secs to plan
Previous Message george young 2003-01-02 15:57:27 Re: preliminary testing, two very slow situations...