oracle itanium vs. pa-risc performance

[Tony Drake_2]

ITanium and PA RISC are different architectures. ITanium is not really RISC, nor is it really CISC...they call it EPIC (Explicit Paralell Instruction...) Since Itanium is "Intel", I would have to think it probably more akin to a CISC instruction set, because Intel has never been big on RISC. They have tried to do quasi-risc architectures with some of the pentium chips where they take CISC operations and decompose them, but they never had a RISC chip Par-Se, at least in the PC realm.

There is no other chip that does things quite like this if I read the papers right...I am not pro or Con mind you...but it has the potential in certain types of software (I am thinking Scientific stuff like I did when in college) it has real potential to be blindingly fast. If programmed correctly, other software has the potential to also be faster than an equivalent non-itanium CISC (like a pentium) or RISC (like PA_RISC).

The thing is that all this becomes a moot point in most situations. I don't deal with engineers or scientists or programmers. I deal with managers and DBA's who want to know how much and how fast.

So regardless of the "correctness", it is easiest for me to say "an 800 Mhz itanium costs X dollars and a PA RISC costs Y, and they are equivalent, or half as fast, or twice as fast"...etc.
Thanks for all the replies. Keep them coming.

[A. Clay Stephenson]

This is essentially an impossible question to answer with anything other than "it depends". The vast majority of Oracle applications are i/o bound, then memory bound, and finally CPU bound. You could very well find that even if you were comparing a relatively slow PA-RISC based box to an Itanium box that as long as the I/O subsystems and memory were comparable, the actual performance differences might be very small. I suggest that you use Glance to the performance tool of your choice to see how much CPU time your "typical" Oracle processes are using and apply a rather safe 1.5X improvement. If the total fraction of the process time is 15% then the actual performance gains are quite small.

Obviously, if this were a CPU bound application (e.g. Finite Element Analysis) then you would see huge differences and the comparisons are easy but in applications where I/O is the bottleneck the CPU's effect may be difficult to measure --- and harder to justify.

The very last thing you want to do is "prove" that the Itanium box is twice as fast based on benchmarks only to find out that 2X is really only 1.05x because the CPU is such a small component. Many managers (and unfortunately many IT staffer's) have bought into the PC mentality that the only thing that matters is that "I have more GHz than you".

[Julio Yamawaki]

Hi,

Let me correct some data:

rx2600 box was powered by a 1,3 GHz Itanium, so, I was checking that the power im TPM-C is about the same as a rp3440 800 MHz: 29000 tpm.
Also, I put rx2600 in production in february, 2004 and rp3410 in november, 2004.
So, Itanium needs more GHz to deploy the same TPM.
In my opinion, when executing long running queries, rx2600 has a better response time than rp3410, of course, with Oracle 9i database.
Also, I'm starting to upgrade some database to 10g and in a few months I will have some real world data about this databases in production in rx and rp box and I will send this for you.

Regards,

[Tony Drake_2]

Julio: thanks. I look forward to it.

Clay: good points. I did not realize that CPU for Oracle was such a minimal component. Most of my servers tend to be pretty heavily loaded.

I will keep that in mind as I size servers and start deploying applications.

[Jeff Schussele · Accepted solution]

Hi Tony,

I have to whole-heartedly agree with Clay here. We have dozens & dozens & dozens of Oracle servers here and they're all different in the demands they present. But we've found that THE common bottlenecks - in order - are I/O then memory & finally CPU.
Our biggest pig DB was not "tamed" until we threw an rp8400 with 8 - yes EIGHT - 2GB fibre channel cards for "normal" I/O & 2 more for the hotbackup - yes we *had* to move that traffic off the "standard" fibre channel cards.
Now the battles we fight are getting the DBAs to optimize table/index layout & more importantly tighten up their sloppy SQL code.
Initially, when we ran 32-bit Oracle, we constantly fought the inherent memory constraints. But now that we're all 9i & living fat, dumb & happy in 64bitville we don't have that problem near as much. But then again when extremely sloppy SQL code rears it's ugly head we can see "some" CPU pressure...BUT....we also see monitoring routines kicking in at the same time. Gotta love those developer-types - their response to application degradation is to fire up *more* processes to "monitor" the situation.
Heh, I guess it's a job security kinda thing for them.
But the Oracle moral is regardless of CPU architecture put *more* money into I/O than CPU & you have a better chance of meeting SLAs my friend.

My 2 cents,
Jeff

[Yogeeraj_1]

hi tony,

I am no expert in this field. But, unless and until you have a properly tuned database and applications running on the your server, you won't be able to reep the benefits of it being state-of-the-art...

My point is that it should be RIGHT-SIZED. Clay mentioned a good point about I/O which is much more important than the CPU when you are talking about Oracle RDBMS.

Should we consider support, lifetime and upgradability? Lots of questions...

Hope experts in this field clarify these myths...

good luck

regards
Yogeeraj

[Tony Drake_2]

Jeff:

How did you determine that the solution was to add more fiber cards?

I have been trying for more than 6 months to find a way to determine fiber card saturation, to no avail.

I have glance, Measureware, PV, etc, but have been unable to do it.

Thanks again all for the comments. They are well taken and very helpful!

[Alzhy]

Tony.. it may not be fibre bandwidth saturation that you will be addressing by providing more Fibre Channels between your server and your storage front-ends but rather a possibility that the array's front-end's queue capacity may be saturated. I/O is the undeniable beast that hinders true database performance (or comparisons). I am in total agreement that tuning queries and Oracle most often provides performance increases but with the tools both external and internal to current releases of Oracle - even the novice DBA will certainly take notice that there is something wrong with a query or a DB operation. Most of the dramatic performance leaps I've seen in Oracle environments in the last 3 years have been in the arena of proper provisioning (and layout) of storage. By this I mean - lumping and spreading out I/O so that it matches your storage architecture. If your using say an XP/HDS array - then the recipe should be to stripe accross however many LUNS from each array group presented on different HBA's/FC paths. I've seen and helped configurations wherein stripes are even accross arrays.

So for purposes of comparing one architecture to another (ie. DB benchmarking) - it is important that whateevr I/O configurationand layout you have on one platformis exactly the same as the other. With PARISC - Itanium comparisons - it is just a matter of providing the same number and kind of HBA's since data is compatible between the architectures.

[Jeff Schussele]

Hi (again) Tony,

It was simply the fact that I/O wait times & queueing on specific FC devices clearly showed that the I/O needed to be spread out.
For Example we had 12 table/index filesystems each on this server across 4 FC cards to start & started seeing higher & higher times/queues on 1/2 of them. BUT it was across several filesystems. SOOOOO we added more cards & spread that load out. That helped. but, we were running on V-class systems & it's bus was not keeping up so we then moved to rp8400 & we are now able to sustain the intermitent burst rates necessary.

Rgds,
Jeff

[Tony Drake_2]

jeff:

How did you measure the wait time and queuing on the FC devices?

Thats what I was asking about, because I have not found any way to look at an FC device directly. Only disk and filesystem metrics seem to be available, which really don't help pinpoint if its the fiber cards or not.

We are working to get EMC control center in so we can see the SAN better, but I would like to be able to see the FC's on each server if thats possible.