Peter,
> When an LPAR is capped due to the R4HA being exceeded, RMF 3 CPC report shows
> this as "WLM Capping %:" being greater that zero. But this alone is
> not an indication if the capping really hurts. If MVS busy (RMF 3 SI report)
> is nowhere near 100%, then the situation is not really bad.
As you already mentioned, the %WLM Capping metric just indicates to what extent
during the interval a cap had been in place. 100% just means that phantom
weight capping was used. The more relevant metric is the %WLM Actual (or %ACT)
metric that identiefies to what extent the consumption of the LPAR was close to
the effective limit.
>Say WLM capping is 100% for a 300 second period, and MVS busy is 63% for the
>same period, then I would say everything that wanted access
>to processors should have gotten access.
Over the interval(!) MVS did still decided to go into a wait 37% of the time.
It may still worth while to check %Actual capping as well as the In-Ready work
unit queue distribution (or processor delays in the Workload Activity Report).
>However, those task working on the processors will work slower due to PR/SM
>taking away the physical CPs from the logicals due to capping being active.
Less dispatch time on the physical processors will be available.
>This is true even for vertial high (pseudo dedicated) CPs.
More precisely: If the LPAR is capped to an MSU limit below it's weight
equivalent (positive phantom weight capping) it's PR/SM entitlement (weight)
gets reduced. That means that vertical highs could become mediums or even lows.
But those logicals that remain VHs will continue to be dispatched as VH
("pseudo dedicated")
In
ftp://public.dhe.ibm.com/eserver/zseries/zos/wlm/Capping_Technologies_and_4HRA_Optimization_2016.pdf
you'll find some more details.
Horst Sinram - STSM, z/OS Workload and Capacity Management
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
