Superdome vpar sizing criteria.

[Steven E. Protter]

Our team has a number of applications coming in that need to run on a very large impressive looking superdome.

When its an application we are familiar with, such as peoplesoft, we look at what it was using on the older rp8420 systems, increase the memory and disk requirements and are pretty good at cooking up a superdome vpar that will run the system. This method is providing fairly good utilization numbers up to this point. We are not wasting system resources, nor is the system under stress, in need of additional resources.

But what about a new application coming in that we've never run?

I'm wondering on a brand new, never ran it application how you determine number of CPUS.

Here are the questions I'm planning on asking the project planner and application vendor:

1) How many users.
2) SGA memory requirements - This gives us a base on top of which we have a forumula to calculate needed kernel,cache and OS memory.
3) Number of transactions the system/application is expected to process.
4) Data disk requirements.


There are a lot of standards out there as far as CPU transactional requirements.

So what questions do you ask, and what standards do you use to determine sizing, particularly number of CPU's when building a vpar for a specific application.

This is not strictly a superdome question, but I'm going to pay more attention to peoples responses who do this with superdome environments.

Hardware/OS
IA-64 Itanium SD
ia64 hp superdome server SD64B
72 CPU's 288 GB of RAM.

Divided into three npars.
vpar software is vPars A.05.04
HP-UX 11.31 is the standard and only OS on permitted on any of the npars.

Looking forward to your answers and rewarding the useful ones with generous point allocation.

SEP

[Steven E. Protter]

bumping.

Nobody ever had this problem?

[Jean-Luc Oudart]

Steven

I believe we all have at some stage similar challenge regarding sizing a server (physical or virtual). And you are right you try to get as much information from the vendor who usually provide some very generic benchmark. If you listen and apply everything they want you probably end up with a system sized with 2x or 3x the amount of resources.

You ask the project who should talk to the business to try to get information on number of users, numbers of transactions, etc.
Probably overestimated ?! Then youfed this into the vendor crunching and you get the vendor requirements as above !

In an ideal world you would have the time and money to go and benchmark the application abd conclude by yourself. I bet you don't have either (or have you ?).

If this is aknown application as indicated in your post and from same vendor (???) you could estimate to some extent from their benchmark on the other application, their benchmark on the new application on your current machine sizing what would be the new one.

Ensure you get from the project team, projection regarding volume of users, transactions ,...

my 2 cents.

Regards
Jean-Luc
PS : not a small system you're having to deal with !

[BUPA IS]

Hello,

We do but I needed some time to think to try and provide a possibly useful answer .
We do not have a superdome at the moment but we do have multi partitioned systems from HP SUN and IBM

Here are some questions I like to ask as well as those suggested before I start thinking about the system it will end up on.
I try to keep these questions more open so that I do not get bogged down in the technology detail before I undertsand the system and the designers requirements.

- The style of the multi tasking ? i.e. Is it truly multi threaded or does spend a lot of time locking things?
This will help determine the cpu count . The former will work better with more and possibly slower cpus and the later will prefer fewer faster cpus. It will also have bearing on the choice and speed of the i/o subsystem

- Its is scientific ? statistical ? customer sales ? transaction/batch/accounting .

_ What is the enquiry to update ratio this will lead into a discussion about cache memory sizes.

- Will it have user based ad hoc searches as well as predefined transacitions? If yes consdider creating an MI copy with little cache .

- Are memory hungry application tool sets being used ? use the manufacturers estimates as a starting guess .

- What are the underlying languages ? we ended up with one written in fortran with lots of floating point calls. (more cpu less memory)

- Are you encrypting any of the data going into the database or out to the user session ? If so add extra cpu power to cope if required (or possibly offload encription cards ) .

- Is there any overnight or month end consolidation batch type work again is this single threaded ?

- How much data is moved out to the users per transaction, have we got to do database and application and even web serving from the same partition . the user count has lot of bearing on this e.g. 100 users 20 000 tx per day all in one 5 000 users 10 000000 tx per day a split it up .

- For relational database systems ask to see the data model and index design this will help with deciding on san/disk layout and how many i/o paths to allocate

- What is the management information reporting requirement, will you have seperate database for this and will it be in a seperate vpar ?

- Do they want user training instance which vpar ( MI or production ) and how do you refresh it and how often ? these last two of course increase the disk space requirements

- If it is replacing an exsisting setup, the users will still go to lunch and open the post a the same time. Plots of arrivial rates and peak usage of the cuurent user base can be quite informative.

- How much logging of audit trails is required is actually needed and is desireable ? How long do they need to keep it all for? Try to avoid the request that could only be achieved by running truss the whole time :)

- Do you need to move large amounts of data to other servers in real time? If so consider network cards with ip offload, and jumbo frames support if appropriate

- If it is a vendor package get the vendor to arrange site visit where the vendor introduces you and goes away to leave the other user to talk to you uninhibited.

- Backup and archiving plans do they want instant recovery offsite ?
Costing this can be quite revealing because it makes them think about the minumum configuration they believe they can run the system with.

- If we can we setup a pilot domain with all the performance tools (glance plus and OVPA and any datbase tools and plugins) and get them to install and run
and get some kind of load running in there this often continues as the user acceptance test area.

And sometimes we just guess and measure and tune, once we have the evidence get them to retune their application or ask for more kit .

I hope this is of some use

Mike

[Steven E. Protter]

Interesting stuff.

Still mulling this over. On existing systems running on say a rp8420, a one to one ratio of memory and cpu to superdome provides headroom. Though I have a script to run capacity analysis to see if an existing system is under utilized.

But for something new, thats hard. Vendors are either fixed in stone, thinking the same number of superdome cpu's are required as they use for their windows product, or refuse to provide useful data.

SEP