On 7-Nov-07, at 9:24 AM, Phillip Mills wrote:
On 11/7/07, Albe Laurenz <laurenz.albe@wien.gv.at> wrote: The problem statement is bad, because why is it a
problem if the resources are not consumed?
No, the statement is fine. It's a problem because it screws up capacity planning by introducing unpredictability regarding scaling. Since user transactions are mostly independent, our experience is that increasing CPUs from 1-through-4 gives approximately linear improvement. Adding more than 4 gives almost no improvement. It's not enough to say that today's performance requirements are met; it's also necessary to have some strategy for expansion.
Since memory problems (other than outright failures) usually present as CPU and disk activity, we can eliminate that. It's not CPU, because that's where I'm trying to bottleneck and not getting there. So whether network or non-network, that leaves I/O. Which is why I started this conversation by asking about the I/O routines that I saw on the thread stacks.
Kris gave me a useful answer to my actual question and I'll go on from there.
Well, if you haven't actually tuned/optimized your database/hardware how can you make any of the above assumptions ? The number of CPU's on a database machine does not usually correlate with database performance.