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

Will investigate further down this track.

Thanks to everyone who responded!



Josh Berkus <[EMAIL PROTECTED]> 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 

> We are running with shared buffers large enough to
hold the
> entire database

Which is bad. This is not what shared buffers are for.

Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of
TIP 1: subscribe and unsubscribe commands go to

Do you Yahoo!?
The New Yahoo! Shopping - with improved product search

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to