Performance Methodology

Velocity Software's Performance Methodology

When there is a performance problem, a hierachical approach is a methodology that will work with most problems. Our suggestion is to start at high level and then as information is evaluated, go to down to the next appropriate level. This is helpful in a mainframe environment. However, Linux measures in 'steal time' and uses a bottom up analysis vs top down. ZVPS is end to end performance management in that it can see/report on everything from the hardware down to the Linux processes running in order to find performance issues. This is a summary of things to consider that will be applied to the rest of the Tuning Guide.

Knowing the current environment is critical! Setting up highlighting, alerts and trending help to pinpoint when/where problems start but can only be done correctly when the baseline performance is known. Often customers don't view performance data until a problem occurs, which may be too late. With some basic knowledge of the "normal" performance levels, it can more easily be seen went/where an event may have happened.
Note: Performance management means the performance monitor should NEVER be the performance problem and should always be running - not turn off when there is a performance problem!

Important ZVPS system/data information:

Planning considerations:

Top Down Methodology:

Knowing your environment:

There are many factors that go into creating an efficient processing environment. Each environment is unique.
Things to think about:

What performance problem needs to be solved?

Problems will show up in many ways such as workload timeouts, applications running slowly, workloads/servers waiting or someone notices high steal time.
Many problems are caused by tuning issues such as (addressed on other pages):

General information flow:

In general, these are good things to investigate. All of these are explained in more details on the flow chart page:

Top 25 Reports at a Glance:

Important Tips:

zVPS numbers: zVPS performance numbers are based on absolute terms. If there are 10 processors, the maximum utilization will be 1000%. It measures CPU seconds and cycles per second. It is not based on percentages of percentages, which can not be used for capacity planning or chargeback, but also is not helpful for performance.
Linux was measured in wall clock time, which is less than desirable. They have added a steal timer, which has helped.
Hardware measurement is the only consistently valid measurement (however with SMT, that is harder to measure.)

zVPS reports:
zVPS information may be found in a zMON screen (real time), in a zMAP report (for the previous day), or both. Also, specific information may be extracted for detailed trending, etc (Extracting Performance Data). Most of the explanations in the tuning guide utilize zMON screens for real time information. However, if a zMAP report is available it will have the same or similar information but averaged over a time frame (usually 15 minutes) for the day to facilitate trending analysis. There are also several reports that have no real time screens as the information is only valid over time. (ESAMON ESAINDEX or ESAMON ESATOC on z/VM or Screen Index on zVIEW zMON) can be used to see available zMON screens and (ESATOC LISTING on ZMAP 191 or ESAINDEX / Custom Samples Maplists on zVIEW zMAP) can be used to see available reports.

Conclusions:

The best performance methodology is top-down. Start at the highest level and work down. However, one of the most important things to do for performance is to know what is typical for the system so when something changes, it is easlily seen. This makes performance issues much easier to determine.

Back to top of page
Back to Performance Tuning Guide