Re: Practical Oracle 8i by Jonathan Lewis?

Trade off between performance and availibility. From an performance point of view if you have a system with many slow cpus and have (contention), you will most certainly benefit from fewer but faster cpu's. I have seen instances where 28 CPU machines were replaced by 12 CPU machines and the 12 cpu machine outperformed the 28 cpu. From an availability point of view if one cpu fails of the 12, we would still be faster than the 28.

Anjo.

Jonathan Lewis wrote:

> Steve and I (as well as several others) have had
> electronic discussions about this recently, and
> it was exactly the type of argument you put forward,
> plus a SMALL number of observations of real systems
> that prompted me into that throwaway comment.
>
> However, I had forgotten Steve Adam's comments
> about the increased costs of maintaining cache
> coherency when the number of CPUs grows - and
> that is certainly a compelling theoretical argument
> that I won't contradict. Certainly it was the big
> problem for SMP systems just a few years ago.
>
> My final conclusion was that Steve is probably
> theoretically correct for a perfectly designed
> and executed systems - but that most systems
> are sufficiently far from perfect that other queuing
> arguments (including quasi-batch/oltp conflict)
> should be considered too.
>
> There is also the thought:
> If you have 4 very fast CPUs and one blows,
> you are operating at 75%.
>
> If you have 10 slower CPUs and one blows,
> you are operating at 90%.
>
> Thank you for your comments on the book, by
> the way. I've been surprised by the number of
> people who've told me that they like to keep it
> by their bedside to read at night. (I think that's
> a compliment, but maybe ...)
>
> --
> Jonathan Lewis
> Yet another Oracle-related web site: http://www.jlcomp.demon.co.uk
>
> Practical Oracle 8i: Building Efficient Databases
> Publishers: Addison-Wesley
>
> Reviews at: http://www.jlcomp.demon.co.uk/book_rev.html
>
> Brian Peasland wrote in message <3AA4FD1C.6E7E3CD3_at_usgs.gov>...
> >
> >
> >> I read his book too, I think it's excellent.
> >
> >I'm in the process of reading his book now. So far, I've found it to be
> >enjoyable and refreshing. It definitely doesn't rehash the same things
> >one finds over and over again.
> >
> >> There is a little comment I disagreed with in there though, he states
> >> that more slower CPUs is better than a few fast ones. My take on this
> >> is that it's better to have fewer, fast CPUs than more slower ones. My
> >> servers don't have more than a handful of active sessions at a time,
> >> though -- maybe that explains why I differ on this point. Also my
> >> servers only have 2 CPUs at best, he may have been talking about 5+ CPU
> >> machines.
> >
> >Feel free to correct me on this one (Jonathan Lewis, James Morle, Steve
> >Adams) but this has to do with queueing theory and how multiple CPUs
> >handle multiple processes. If you only have a handful of active sessions
> >at a time (thus a low number of processes), then I believe that you will
> >find a few but fast CPUs will perform really well. But you don't have as
> >much contention for CPUs and other system resources as you do when you
> >get a very large number of processes. In that case, more slower CPUs is
> >better than fewer faster ones. This is assuming that your total MHz is
> >the same, i.e. 4 * 200 MHz = 2 * 400 MHz. In this case, go with the 4
> >slower CPUs rather than the 2 faster ones. But in the end, you'd
> >probably be better off with more, faster CPUs!!!
  Received on Tue Mar 13 2001 - 03:35:17 CST