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 <[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 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 [EMAIL PROTECTED] __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
