Jan,

Omegamon has no way of attributing MVS overhead.  It simply subtracts the RMF 
processor busy time from the interval time and reports the difference.

Being time-driven, WLM uses very little CPU on it's own behalf.  In fact, as 
has been pointed out, when capping is in effect, IRD weight management is 
suspended.

Bear in mind that there is an RMF on each LPAR, but there is only one PR/SM 
hypervisor.  If I'm not mistaken, LPAR management time is over and above MVS 
uncaptured "overhead."

Not much can be done about high RNI.  If a new machine exhibits abnormally high 
overhead, or if an application's performance is severely degraded and you can't 
explain it any other way, type 113 sampling data might offer a clue.  However, 
HIS sampling is not intended for use under normal operation.  I would recommend 
asking an IBM technical support representative for guidance.

db

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Jan Vanbrabant
Sent: Thursday, February 21, 2013 3:34 AM
To: [email protected]
Subject: Re: ''MVS overhead'' (as indicated by OMEGAMON)

Hi Dave & co-listers,

1°
Is  OMEGAMON capable of drilling down into "MVS Overhead" ?
If not, how can further PD (Problem Detemination) be done?
2°
Is the CPU-MF HIS approach based on SMF113 not too  long-winded and over-doing?

CPU-MF (HIS)  NOT being a substitute for traditional performance nor capacity 
metrics.  And it does NOT indicate either the capacity being achieved by the 
LPAR or processor

3° Where is "*phantom load*"   (or a *"phantom" logical partition) *
and  "*cap(ping)
pattern*" reported?  IF reported.   Or where can we find it?

SG24-6472-03 System Programmer's Guide to  Workload Manager (WLM) (last update 
20 april 2010) (applies to zOS V1R8 - Maart 2008) 
http://www.redbooks.ibm.com/abstracts/sg246472.html
3.4 Soft capping   (page 101 ... etc ...)
3.4.1 *Defined capacity*
When WLM caps the logical partition, there are three possible scenarios:
 *1° The percentage share of the logical partition processing weight is equal 
to the percentage share of the defined capacity.*  *(relative weight = defined 
capacity)* In this case, the capping is done at the logical partition 
processing weight. This is the best and recommended situation.
 2° *The percentage share of the logical partition processing weight is
greater than the percentage share of the defined capacity.*   *(relative
weight > defined capacity)*
In this case, capping at the weight has no effect, because the logical 
partition has more MSU than allowed. To enforce the percentage share of WLC, 
PR/SM subtracts a certain number from the logical partition processing weight 
to match the desired percentage share and calculates a *"phantom"
logical partition* that receives the remaining unused weight. This guarantees 
that other logical partitions are not affected by the weight management, 
because the total logical partition processing weight stays the same.
* 3° The percentage share of the logical partition processing weight is
lower than the percentage share of the defined capacity.*   *(relative
weight < defined capacity)*
WLM defines a cap pattern that repeatedly applies and removes the cap at the 
logical partition processing weight. Over time, this looks as though the 
partition is constantly capped at its defined capacity limit.
The *cap pattern* depends on the difference between the capacity based on the 
weight and the defined capacity limit. If the weight is small compared to the 
defined capacity, the capacity of the partition can be reduced drastically for 
short periods of time. This can cause performance to suffer. Therefore, we 
recommend to keep both definitions as close as possible.

Where is "phantom load" or the "phantom logical partition" reported?   (IF
reported !?)    Where is "cap(ping) pattern" reported? (IF reported !?)
RMF ???

Is "cap pattern"  part of the "MVS Overhead" ?  Because WLM must be working 
like hell.

Please, enlighten us.
Jan

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to