Sizing servers for Oracle Products

[Jeff Schussele]

I hear you there Andrew.
This is one of the nits I have to pick with these new "slim" servers.
For crying out loud - two, TWO!!, slots are not enough for *any* server - like a 3410. Sheesh - I've had more expandibilty in laptops I've used - WHY should a server be that handicapped?!?!?!
Then you get into the issue of just what kind of "ropes" you feed these slots with. EX: slots 7/8 have 1GB bandwidth on the 4440 & the others go from 512MB down to 256MB.
So one *must* be very dilligent in how they populate these slots.

OK - off my soapbox,
Jeff

[Andrew Moody_1]

Quite Jeff

After all, two pci slots, so you add a single hba card and another 1000Mbps ethernet card and it's full.

But then they've got to lever us to buy the bigger form factor servers somehow eh?

Thanks guys btw for all your suggestions so far, and if anyone has any more information I'd be glad to glean it. After all, as I said further up the list, I've been at this only a matter of months.

Cheers

[TwoProc]

Andrew, keep this in mind while sizing...

Four PA-8700 procs are actually four whole and separate procs. Let's say they are 750Mhz.

2 PA-8800's or 8900's whole be one dual core chip running at 1Ghz. The problem is that these two chips are one core, and are sharing cache. Even HP will tell you that the benchmark for this dual-core chip is only 50% more than a single chip(PA-8800s anyway). This would effectively give you 1.5Ghz of proc power.

This means that you now have basically the SAME total horsepower as two 750 Mhz PA-7500's !

While I've found that this is not quite a true statement (as I have both), it's probably closer than you would be comfortable with.

However, if you're running 440 Mhz or 550Mhz chips (as my older Ls and Ns do), then the upgrade as per your discussion would do you a world of good.

Keep in mind that you mentioned having "2 or 3" procs - dual core chips come in sets of two naturally, and 3 isn't doable.

So, let's say you scale down to 2 procs from four. While you may have the same total HP in Ghz (and probably more than), you will unfortunately have less divisibility for tasks. That means that only two very intensive (and probably not well tuned) tasks can put your server at 100%, leaving poor response for everything else. On your old configuration, you'd only be at 50% at this point. As a case in point, you ever notice that a two proc server *seems* to run about four times faster than than a one proc? It's because on a one proc, ANY meaningfully sized single process and can and will push the server to 100%. So, in your case, it would be two processes as the 100% mark, and after that it's welcome to "time slice and wait" city.

[Andrew Moody_1]

Thanks John, some things worth mulling over and factoring in.

L-class and N-class generally have 4x 750Mhz PA8700
one N-class has 3x 875Mhz PA8700

No machine has more than 12Gb of RAM

We have N-class machines running as oracle apps servers which I want to replace with smaller (rp3440) machines but as powerful machines. Then redeploy the bigger older machines as database servers for the development environment. I figure I can upgrade both production and development this way for less than it would take to put in a an all new development environment.


That's my current train of thought...

[Mark Greene_1]

From my limited experience, the Oracle sizing tools are highly dependant on the accuracy of the data: the number of users, the type of data use (update vs report only), and the overall growth-rate of the database (not just the size). Changing one or more of these numbers one order of magnatude up or down can make a big difference.

Also, 9i and 10g take progressively more memory, which is driven in part by the java requirements. If you have a webserver requirement with any sort of middleware to drive the app, you're memory requirements will be even greater.

mark

[A. Clay Stephenson]

Since you are planning on using your older boxes in the development environment, let me make a whackball suggestion. Intentionally cripple the old boxes even more. Remove some of the processor's and reduce the memory? Why? Because if the code runs well enough on the intentionally crippled boxes in test/development, it stands a much greater probability of scaling up well in the production environment. I can't tell you the number of times that I have seen code fly in test/development and die like a dog when deployed in production. Algorithms that run well on a dog generally will then run well on a newer, faster box.

[Andrew Moody_1]

Thanks Mark.

Clay, my only problem with that would be judging the amount by which to handicap the older boxes.

I was thinking I could harvest a little of the old internal hardware to scale up the production database server, but to do that I'd need to purchase more Core i/o, cell board etc which would start to make it exspensive again.

It's all good stuff though guys, every response adds to the knowledge from which eventually I'm going to have to make a decision.

[A. Clay Stephenson]

Surprisingly the answer as to how much to "handicap" (I suppose in the interest of political correctness that we should say "physically challenge".) a development box is more rather than less. Our developers run on an old K-box -- intentionally; and yes, they did howl initially. I heard things like "Compiles take too long; I can't meet deadlines." Unfortunately (for them), I had done enough development over the years to know that compile/link times are perhaps 1% (and that is an extremely liberal estimate) of the total development time. After coming to understand my reasons, everyone came on board with the "dog" approach and essentially we have no "scaling" problem when new code is moved to production. The fact that having your developers working on a "dog" annoys them is an added bonus.