RSS Feed

Method R Discussion Group

Hi Cary,

Suppose we have 28 CPUs (model sparcv9 (sun4u)) of 0.9GHz and we want to move the hardware from Solaris to Linux and CPU should also be to 3.39GHz. Currently these CPUs (28 of 9.9GHz) are not enough to handle our workload and also we are also expecting to have workload increase.
What should be the approach to dertermine number of CPUs i.e. upgrated one?

Thanks,
Suraj Sharma

Hi Suraj, this is a great question and something you should consider, perhaps, in multiple phases.

First, you should seriously study the utilization of your current system to see if your application's consumption of capacity is justifiable and fair, or just gross and untuned.  Recently another customer asked us, "Our big SMP box is maxed out, we have US$1.6M to spend on a new one, what should we get?"  After a few weeks of consulting we were able to show them that with a little application tuning, and a few other small adjustments, they could get back to 50% idle on their current box, absorb expected growth in certain areas of their application, and still stay on the same old box for at least 12 more months.  It could definitely be worth your while to challenge your assumption that you need to fix your current problem through hardware.

Secondly, let's assume you really do need or want to migrate to a new platform.  Given how big your current platform is, and that you're thinking Linux, I would assume you're also thinking RAC.  It is true that the difference in hardware procurement costs makes Linux and a cluster of smaller servers attractive, but do you really need/want RAC?  I have seen RAC work well for many customers who really need it, but those customers also went through a very careful process to evaluate RAC and understand its features mapped to their requirements, and all the operational and cost considerations behind that move.  I have seen other customers at least surprised by if not unhappy with their RAC decision once they get into the interconnect costs, the operational/skillset costs and implications, or the potential application scalability challenges which could require nontrivial "fix" efforts at the workload balancing or application level, or even at the table partitioning and physical level.  If you need RAC because you want an HA or horizontal scalability solution to fix your HA exposure today with a single SMP box, then great.  If you want RAC only because it will help you cluster some smaller servers together, and "gang up" the capacity of multiple servers then open yourself to a bigger conversation.

Thirdly, assuming you now are running Solaris version x and Oracle version y on the current platform, you will be running a whole new OS, and perhaps even a new db version on the new platform.  Your question about comparing cpu speeds is not broad enough - you need to consider how you will find out as much ahead of time, study and compare, the differences in how your application will behave on the new platform versus the old.  What you propose to do is actually a nontrivial migration project, with many changes not only in infrastructure but probably also how you will manage and support the environment.  Customers purchase our Laredo tool to help them with this kind of comparative analysis.

Fourthly, looking at box capacity, you need to plan if you go RAC that RAC itself will require some cpu capacity per node.  You will have to that into the cpu calculations that follow later in this note...  Before I worked at Hotsos I managed the Oracle datacenter performance team; among other things we were responsible for Oracle's own large production 4 node RAC running the E-Business apps.  The LMS and other RAC-related Oracle background processes, per node, consumed on average 15%'ish of each node's cpu capacity.  That was back with Oracle 9i RAC, I'm not sure what the current numbers are for 10gR2 RAC.

Fifth, your question of cpu could best be answered by setting up a lab with two nodes of the configuration you propose, installing your database and application over there, and doing tests.  In that way you will get much more accurate measurements of application activity compared to cpu consumption, than we could ever postulate in a note.  For production systems Hotsos recommends a minimum 3-node RAC configuration, and a minimum of 4 cpu's (or core equivalents) per node.  You should isolate key transactions in your application then trace them on the old and new system, and use our Profiler tool to measure and compare cpu second consumption between the two systems.  Then you could extrapolate based on current overall application activity and projected growth, to forecast how many cpu-seconds of capacity you would need on the new platform cpu type to project how many cpu's you would need; however, then you will have to adjust for any other non-application cpu consumption occurring on the new box during your tests (RAC background processes, for example) and make adjustments.

Hope this helps; thanks and regards...

Reply above is from Larry Klein.

Thaks a lot Larry for this explanation. The reason we are looking to move to new hardware is that the client have their DB and CCR on the same server and the CPU also having less speed. The server already have 28 CPUs and the forecasting shows we may require 12 more CPUs to handle the increased workload. Not sure if recommending for new hardware will be good or not thats why I thought to have a view on this.

One more small query (may be its a confusion I want to clear) can a LINUX box only handle 8 CPUs? or more than that? And is this a right approach saying that currently we need 40 CPUs with 0.9GHz and if we upgrade our CPUs to 2.39 GHz we only require 16 calculation like (40*0.9)/2.39 ??

Hello Suraj, thank you for your followon note.

By CCR do you mean CCM - Concurrent Manager?  Is this an Oracle E-Business implementation?  If so, and if currently the server is a "single node install" by which all the database services as well as the  Concurrent Manager plus all the Forms are all on the same box, then there is an easy strategy.  Pardon my rambling but this is a familiar topic for me if indeed you are using E-Business.

Many Oracle E-Business customers for a number of years now have implemented a two-tier configuration with E-Business; tier 1 - a middle tier, supports Apache, Forms, Concurrent Manager, ...  - all the "Application Code Tree" stuff.  Then all of that connects via TWO_TASK to tier 2 - the database server.  Having only one APPL_TOP on the middle tier gives you only one application code tree to support there.  You still will have a number of Oracle_Home's blended into the middle tier, in addition to the Oracle_Home on the database server. 

Runaway application Forms processes consuming CPU, needing to be detected and killed, have been an E-Business issue for years.  By separating the application and database between two tiers, you will better protect the database query processing from runaway application behavior, and vice versa. 

It used to be in the days when so much of the batch jobs were Pro*C based, there was a flurry of packet traffic between the application code and the database; in that case there was a clear advantage to localizing that communication to IPC between the two processes, each running on the same physical server.

With the Apps 11i more and more of the application implementation is to have a little stub Pro*C program, maybe, call PL/SQL packaged procedures, so it is less important (unless you are using the older Financials batch jobs some of which still do the heavy SQL-imbedded-in-Pro*C approach) to localize Concurrent Manager and database processing on the same tier.


Again assuming that you are an E-Business shop (please confirm) then I would recommend you:
* measure on the current platform which processes take more cpu - those related to the application or those related to the database
* assuming the database query and other processes dominate the db server, then buy one or more Linux servers and reconfigure your E-Business to move the APPL_TOP and load-balance/distribute your application to that/those tier(s).  There are various Metalink notes to help you.  You even could use the CCM PCP Parallel Concurrent Processing to have a CM on each of the tiers.  Your Forms users will enjoy a faster screen repaint, given the increased speed of the cpu's on the Linux middle tiers.

With this two-tier architecture change and the offload of cpu cycles for application processing from the db server to apps servers, plus with a little bit of analysis to study how the db server is being used (untuned SQL, too much batch being run, ???) you should enjoy much more life with your current (and already full depreciated?) db server.

Just a last note - the simple ratio math you propose is not a good way to compare capacities.  Any sizing based purely on cpu clock speed comparisons will put you in a world of Giga-Hurts. :)

I hope this helps; thanks and regards, Larry