The suggestion that we are saturating the memory bus
makes a lot of sense. We originally started with a
low setting for shared buffers and resized it to fit
all our tables (since we have memory to burn). That
improved stand alone performance but not concurrent
performance - this would explain that phenomenon
somewhat.
Will investigate further down this track.
Thanks to everyone who responded!
Cheers,
Simon.
Josh Berkus <josh@agliodbs.com> wrote:Simon,
> The issue is that no matter how much query load we
throw at our server it
> seems almost impossible to get it to utilize more
than 50% cpu on a
> dual-cpu box. For a single connection we can use all
of one CPU, but
> multiple connections fail to increase the overall
utilization (although
> they do cause it to spread across CPUs).
This is perfectly normal. It's a rare x86 machine
(read fiber channel) where
you don't saturate the I/O or the RAM *long* before
you saturate the CPU.
Transactional databases are an I/O intensive
operation, not a CPU-intensive
one.
> We are running with shared buffers large enough to
hold the
> entire database
Which is bad. This is not what shared buffers are for.
See:
http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html
--
Josh Berkus
Aglio Database Solutions
San Francisco
---------------------------(end of
broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to
majordomo@postgresql.org
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com