Dual-core CPU vs. very large cache

Erich Dollansky oceanare at pacific.net.sg
Wed Apr 26 04:01:17 UTC 2006


Bill Moran wrote:
> We have some database servers that we're looking to replace with
> beefier hardware, mainly because we're expecting our customer base
> to grow a lot in the near future.
> The current hw is Dell 2850 servers.  These are dual proc (each proc
> is hyperthreaded) with Dell PERC controllers driving 4 SCSI-320
> disks in a RAID-10.

SCSI is really the minimum here.
> We're considering two alternatives for the newer hardware:
> 1) Intel HT CPUs with 8M cache
> 2) Intel dual-core procs

Forget both. Opterons have a much better memory interface which helps 
here a lot.
> Our current Dells have 2M cache, and I'm trying to determine whether
> the 8M cache will make a significant difference or not.  Can someone

You have a simple problem. Even if you have a large cache, it has to be 
refilled very often. The limited memory band with of Xeons will be of an 
disadvantage here.

Take an Opteron motherboard where every CPU has its own memory slots. 
Take the CPUs with the larger caches. Dual core plus at least two CPUs 
help also.

> recommend a testing procedure for determining whether adding cache is
> worthwhile or not?  I can simulate a test load at any time, but I
> don't know how to tell whether the cache is the bottleneck of the
> CPU or not.
You will never be able to answer this in general. I did some time ago 
tests with Oracle running on a 24 CPU machine. There are situations 
where most CPUs are idle because all CPUs work on locked parts off the 
same table and there are situation where all 24 CPU are working on 
different parts of the database bringing speed to extremely high levels.

As long as you do not know your future scenario and if you have the 
money, get first the highest number of CPUs possible and add then dual 
core if possible.


More information about the freebsd-performance mailing list