Hi,

A customer of mine is  HiperDispatch with “defined” capacity”  (hence
possible softcapping based on the 4Hr-rolling average.)



In the the ‘*System CPU Utilization table view’* of Omegamon XE on z/OS,
and more specifically in the ‘*Workload CPU Usage bar chart* ‘  we  regularly
see (very) high values for the ‘MVS OVERHEAD’ attribute.

Some examples:

1°

Average CPU Percent:  19.5  (TCP % 19;  SRB % 2; partition overhead
negligible)

MVS OVERHEAD :  13

2°

Average CPU Percent:  82  (TCP % 50;  SRB % 2; partition overhead
negligible)

MVS OVERHEAD :  31

3°

On a small system on the contrary,  the MVS OVERHEAD is small.

Average CPU Percent:  27  (TCP % 22;  SRB % 6; partition overhead
negligible)

MVS OVERHEAD :  2

This system has bad P/Is, for example one Service Class has a P/I=18.5
while there are  no bottlenecks at all with the resources, while being  idle
for 96,9%.





We would like to know how we’ve to interpet <MVS OVERHEAD>.

The user’s guide explains it as:

                CPU utilization percentage that is not attributable to any
user or address space. It is calculated as the difference between the total
software utilization times and the total hardware time ((TCB + SRB)-CPU)
over the last reporting interval. Valid value is a 4-byte integer.

                In a complex with more than one CPU, z/OS overhead can be
computed based on the number of processors, or normalized to a maximum of
100%.



???

Any of you able to explain this in a better way?   (So that I’m able to
understand what this means.)



And where should we start looking to find out what’s happening underneath?

Poor  WLM definitions?   (The performance is n't bad finally.)

But if the overhead can go down,  MSU-based CEC invoices are loweedr;  so
the point of view is rather cost-oriented.





In this sysplex  with 6 systems, 34 ServicesClasses are actually
defined....

In the system of the second example, 16 SCs of the 34 are actually used.

(I don’t know if it might be important, but on top of the 34 there are
another 8 system SC’s with

 a goal of SYSTEM; they are SYSTEM, SYSSTC, SYSSTC1,  SYSSCT2, SYSSTC3,
SYSSTC4,  USSCT5, SYSOTHER).





IBM-MAIN is probably not the  most appropriate listserver or forum to post
this OMEGAMON-based question at the origin?  Is there a better place at
your knowledge?



Jan



PS

Customer already reduced the number of logical processors  by running Alain
Maneville’s  EXCELLENT (!)  LPARDesign-HD-V3-spreadsheet.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to