VM Performance and Capacity Sizing Considerations
This is a list of considerations I put together after having a
particularly bad month in terms of critical customer situations that
could have been avoided or made more manageable.
Many performance problems are really a matter of setting expectations
too high or improperly. While I can appreciate that it is sometimes
difficult to do sizings with 100% confidence, there are a few things
that you can do to increase the chance of success.
1. Do the homework, don't rely on cheat sheets.
Do the homework, don't rely on cheat sheets.
Anyone sizing processors with little more than a cheat sheet with a
single column of numbers is asking for trouble.
Use official sizing tools and z/VM Performance Reports.
2. Be specific when you define Performance
Be specific when you define
Is it ITR, interactive response time, or elapsed times on batch jobs?
How are you measuring that?
3. Be careful when inverting ITR and percentages.
Be careful when inverting ITRR and percentages.
If the ITRR between
processors A and B is 1.50, that means the throughput per processor
second is 50% greater on B. It does NOT mean that processor B uses
50% of the processor for the same work. The inverse (1 / 1.50) is .67,
Analogy: Car A gets 20 miles per gallon, Car B get 30 mpg. The
MPGR (itrr) of A to B is 1.50 (30/20). So it would take 3 gallons to
go 60 miles in Car A. In car B to go 60 miles it would take
2 gallons (or 33% less gas than it took in car A = (3-2)/3 ).
4. A faster processor may not lower processor utilization.
A faster processor may not lower processor utilization.
This is a footnote to number 3. Do not expect the CPU utilization
to go down just because you have a faster processor. More times
than not, more work will occur. (example, if my compile use to take
1 minute and it now takes 10 seconds, it is unlikely that I'll sit
around for 50 seconds before I issue my next command.)
5. Upgrading a resource which is not the bottleneck, will not make
the bottleneck go away.
Upgrading a resource which is not the bottleneck, will not make
the bottleneck go away. In some cases, it might even make it worse.
6. Removing one constraint will reveal another.
There is always a potential limit somewhere unless you have
Removing one constraint will reveal another.
7. Collect appropriate performance data prior to making any change.
Collect appropriate performance data prior to making any change.
This allows us to prove/disprove the performance change and help identify
any changes in the workload. In some cases, you do not need to
reduce the raw data; but at the very least it should be collected.
8. Use intelligent change management.
Use intelligent change management.
Change as few things as possible at a time, and thoroughly document
all changes. Change management is my friend.
9. Latent demand.
If a system bottlenecks on
a resource and you remove that bottleneck, it is likely that
additional work will get done. See number 4 above.
Research was done years ago which showed as response time improved,
think time decreased. Pretty wild stuff!
10. Do not substitute non-VM numbers when VM numbers are unavailable.
Do not substitute MVS or Linux or whatever
numbers when VM numbers are unavailable.
If you can not find a VM number, do not try fudging by using something
While it can be valuable to know where other
systems stand to get a worst or best case number, a blind substitution is
Return to the Performance Tips Page