Date: Wed, 26 Apr 2006 12:00:38 +0800 From: Erich Dollansky <oceanare@pacific.net.sg> To: Bill Moran <wmoran@collaborativefusion.com> Cc: freebsd-performance@freebsd.org Subject: Re: Dual-core CPU vs. very large cache Message-ID: <444EF066.1090405@pacific.net.sg> In-Reply-To: <20060425090739.8470143f.wmoran@collaborativefusion.com> References: <20060425090739.8470143f.wmoran@collaborativefusion.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, 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. Erich
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?444EF066.1090405>