Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Comment on 'Practical Oracle 8i'

RE: Comment on 'Practical Oracle 8i'

From: Gogala, Mladen <MGogala_at_oxhp.com>
Date: Thu, 16 Aug 2001 08:10:03 -0700
Message-ID: <F001.0036D279.20010816080054@fatcity.com>

> -----Original Message-----
> From: Christopher Spence [mailto:cspence_at_FuelSpot.com]
> Sent: Thursday, August 16, 2001 1:16 AM
> To: Multiple recipients of list ORACLE-L
> Subject: Comment on 'Practical Oracle 8i'
>
>
> Well, I just got this book, and just started reading through it.
> Looks good so far. Just would like to comment on something I saw.
>
> Must say BookPool.com is so awesome. 40% off most books
> (which I bought
> three this time) and paid $4 for 5 day shipping yet I get it
> the next day on
> my doorstep. Got to love that.
>
> Page 28:
>
> I will quote:
>
> "A greater number of slower CPU's is often better than a
> fewer number of
> faster ones."
>
>
> To some extent I believe this is true especially with the
> efficient use of
> caching in most OS's. But with the larger caches on unix
> cpu's, 4Mb, 8Mb.
> There is a loss of performance when a process runs on a cpu,
> then context
> switches and then placed on another cpu. All the cached
> tlb's are then
> sitting on another cpu and need to be reloaded. Although the
> os will try to
> reschedule recently run processes on the same cpu, that doesn't always
> happen on a busy system. Also the fact that faster cpu's return the
> processes back faster.
>
> Although on the other hand, with more cpu's, more can get done
> simultaneously but at a slower rate. And there would be fewer context
> switches with many more cpu's.

You, of course are right. SMP is an overhead. The additional problem with the slower CPUs is that the bus on the machine is usually slower then on newer machines with the screamingly fast CPUs. Slower bus and oracle means that large scatter/gather ISO and memory requests will compete for the bus resources slowing the machine down. Interrupt arbitration (the time spent by the system bus (a.k.a. "chipset") to decide which CPU should be honored by the pending interrupt) is also a huge drain on the slower buses. That can bring systems with the slower buses to the grinding halt. One needs buses and OSes which support memory mapped access ("IntelliIO","NgenIO") and large quantities of IO per second all while featuring advanced CPU cache interconnects which will diminish the impact of cache synchronization on the system. It is worth noting that oracle, nd the same applies to all huge software systems, does not make very good or efficient use of CPU caches. With oracle, cache flushes and invalidations will happen frequently, as well as TLB invalidations and flushes. In order to behave well on virtual memory systems, it is necessary that the programs obey the locality of reference principle, which is very hard to do if you are using a huge software system written thousands of programmers and using thousands of subroutines. With oracle, modern super pipelined, super scalar chips with several execution streams will not do much. The thing that counts is the raw chip frequency and the speed of memory access (DDRAM,EDO,Rambus). To make a long story short, I do prefer a system with more fast CPUs over the system with fewer fast CPUs because the architecture improvements on the modern buses are amazing
and must be used.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Gogala, Mladen
  INET: MGogala_at_oxhp.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Thu Aug 16 2001 - 10:10:03 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US