Re: Physical CPU? or multicore?
Date: Wed, 6 May 2009 00:51:55 +0800
Thanks for all the response, they are all very informative..
From my point of view, Yes, I believe on the answer that "it depends". From the hardware perspective there are many variables that need to be considered (cache, clock speed, architecture, etc) and by looking at the specifications of the processors you may already have an idea which one will perform better. But getting the full power of these CPUs also depend on other factors like the OS/kernel running, the Oracle configuration, Application behavior or any scalability issues you may have.
So I think, benchmarking the application on the CPUs itself would be the best move. But that rarely happens so you'll be left with hard estimates and fancy vendor figures that will make you decide on which to pick..
I had a customer before who migrated their database server from Windows with 2 dual core Xeon processors to Suse Linux (on zVM) on IBM system z with 1 processor (I believe it's quad core, and with bigger cache and faster clock speed). On the first day of production, the run queue was reaching 70+ that is when the OLTP users started to come in. And when I was troubleshooting, my culprit is the CPU that it can't handle all the load with all the arrival of the transactions, well the company having invested a large amount of money is saying “it's an Oracle bug”. But on the off-peak period when they were processing their batch jobs, most of the jobs have service time cut to half. Clearly the number of processors are not enough on the OLTP workload which they've never encountered on their 2 Dual Core Xeons. Kinda weird :)
Maybe that's why I asked my original question...
I hope it would be straightforward just like comparing which is better “faster CPUs” or “additional CPUs” using forecasting models. But take note.. there are other factors..
On Wed, Apr 29, 2009 at 8:30 PM, J Buchanan <oracle_at_digistar.com> wrote:
> Having said all that the CPU is not the unit of measurement I am not
>> concerned with. How many IOPS against given storage (or if really
>> pushed Java/C# TPS) would be my measurement, and it would be on a
>> per-server basis.
> I totally agree - storage is the lifeblood of a database and is often taken
> for granted.
> DBAs that are lucky enough to not have IO throughput issues are lucky
> people. Those of us who have to deal with poor IO performance fight a
> (usually tremendous) uphill battle to get it improved.