Searcing for Processor "best practices"

[Steven Schweda]

> avarege is not really important. [...]

I'm with him. What, exactly, does the
average tell you? What, exactly, matters?

If all your work gets done soon enough, then
why worry about adding hardware? If some of
your work does not get done soon enough, then
you have a problem to solve. (Possible
solutions include faster hardware or faster
software, but also things like more efficient
job scheduling, or a revised definition of
"soon enough".)

If you plan to increase the workload, and
you're currently consuming close to 100% of
some (any) resource (at some time), then you
can reasonably anticipate some trouble.

> This is definitely a "it depends" question.

I'm with him, too.


> [...] we actually have more than the cost
> effective need of processors.

What, exactly, does that mean, in English?
You have more processors than you think you
need?

[Rob Hussey]

My thought is that if we are not using 80% of our available resources 90% of the time, if we more processors, we'll be not using even more money that we have spent on hardware.

My thought is to size the system for 85% to 90% of the ussage and not size a system for 10% to 15% of the time.

[Zinky]

My thought on the matter having been in this business for so many years and leading/herding/guiding bean counters is as follows:

IF the 5 to 15 % of the time that the system gets to peak system Load is important for the business/client - then size FAT. Buy/size your system with enough resources to meet that 10 to 15 per cent peak requirements. Management and its bean counters should be smart enough to tell if say billing and MASS jobs (most typical enterprise peak periods) merit the splurge on IT Systems.

IF the 5 to 15 % is not that really important and your SLA is flexible - then size LEAN.

So you see it all depends.

[Zinky]

I forgot to add and share something very important to this thread which should really have been titeled System Utilisation Best Practices.

We have been in the same predicament for over 7 years now. Our systems are widely varying - with onlines generally light but unpredictable and batch and month ends generally heavy. The dilemma back then was whether to buy small or mid sized systems or go with the big Domes and implement a scheme where resources - mostly CPU can be allocated on demand and on the fly - aka vPars.

It was the BEST solution. We have had agile systems and I think saved a TON of money going this route with systems readily (on the fly or with a short downtime) reconfigurable to address varying workloads. So No wastage of CPU resources. Looking back at my system historicals -- we've been able to utilize up to 80% of CPU resources on average.

In your case - you can likely do the same. HP's partitioning continuum is the best out there for UNIX systems. You can do vPars, IVMs, Psets, WLM groups, etc.

Now that we are almost through with our UNIX-away project and on Linux -- the choices for higher CPU utilisation whilst having an agile system are endless. There's HA/Virtualization using KVM or vSPhere so we truly now have higher agility and efficiency in using system resources whilst lowering costs.

[Rob Hussey]

Thanks Rita, Alzhy and everyone else!!!!


Well, guess that one comes down to - which is cheaper, spending time for some programmers who didn't write it right the first time to find their garbage and fix it -or- buy some hardware just to address that 10% of the time peak load.


IF the 5 to 15 % of the time that the system gets to peak system Load is important for the business/client - then size FAT. Buy/size your system with enough resources to meet that 10 to 15 per cent peak requirements. Management and its bean counters should be smart enough to tell if say billing and MASS jobs (most typical enterprise peak periods) merit the splurge on IT Systems.