Integrity Servers
1748153 Members
3690 Online
108758 Solutions
New Discussion юеВ

Re: Number of cup cores forecast from switchover to Itanium from RISC

 
Amit Jindal_1
Frequent Advisor

Number of cup cores forecast from switchover to Itanium from RISC

Hi,
My project is planing to switch services from one hard partition from RISC based processor server ( SD32000 ) to BL870C Blade server.
The server is of development status. How to do the target number of cpu forecast ?

I have a question regarding the CPU calculation. The SD npar is 60 % cpu lodaded on average. ( rare peaks 99 % ), mostly Oracle DB's are there heavy memory usage though!

The SD npar cpu is PA8700 ( 750 MHz, 4 CPU's )and the new planned server BL870C uses Intel Itanium ( 1.6 GHz cpu cores ), so in total in broad figures for SD 4 CPU's = 3000 MHz or 3 Ghz, so if I use 1 Intel itanium cpu 9150N i.e 2 cores of 1.6 Ghz approx to 3 GHz.

So am i safe in this crude type of calculation, if I go with one blade server.

If someone has moved from RISC to Itanium , how's the CPU side performance as per your experience.

The server will host around 3 TB of database files,2 TB + 500GB + 500GB DB's ( 3 DB's ), but are not so I/O intensive. So planning to use 2 mezannine HBA cards.
2 REPLIES 2
Dennis Handly
Acclaimed Contributor

Re: Number of cup cores forecast from switchover to Itanium from RISC

You should have continued your other thread. Just reply with the additional info.
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1255275
Amit Jindal_1
Frequent Advisor

Re: Number of cup cores forecast from switchover to Itanium from RISC

Hi Dennis,
Thanks for the reply, This is my first posting in this forum. I thought the subject of the earlier thread was not related to my question so I closed a opened a new thread.

In last thread the i/o requirement was asked which i have given.

The server will host around 3 TB of database files,2 TB + 500GB + 500GB DB's ( 3 DB's ), but are not so I/O intensive. So planning to use 2 mezannine HBA cards.

The db's are not heavy transctional type, most of the huge size is due to historic data stored in table partitions.