LPAR Weights

LPAR Weights Analysis

Specifics - LPAR weights/overhead:

It is crucial for a well performing system to have the correct LPAR weights/shares or entitlement is defined. Understanding LPAR entitlement is critical to understanding CPU resources available to each LPAR.

Entitlement is the amount of real CPU time each partition can use at its discretion.
Entitlement for an LPAR with shared CPUs is a calculation of:

The LPAR's weight
The sum of the weights for all other shared partitions and
The number of shared physical CPUs in the CPC.

CPU polarization:

Horizontal - each CPU gets an equal portion of the LPAR weight.
Vertical-High - based on LPAR weighting, vertical high CPUs have high entitlement. It is entitled to run 100% busy.
Vertical-Medium - based on LPAR weighting, vertical medium CPUs have medium entitlement. It can have any entitlement from 0-100% based on the partition's total entitlement and the number of logical CPUs sharing that entitlement.
Vertical-Low - based on LPAR weighting, vertical low CPUs have low entitlement. It is entitled to nothing.

High overhead and high thread idle time may indicate too many virtual cpus (vcpus) are defined.
The accuracy of the current LPAR entitlement will be seen in the following screens.
From a business planning perspective, this becomes a critical metric for providing specific workloads with the required processing power.

ESALPARS - Shows the processor sharing configuration and utilization for each LPAR. Examples of both ESALPARS report (daily) and screen (real time).

Phy CPU - This is how many physical CPUs are on the box. The ESALPAR report will show how the totals by processor type. This box has 2 CP, 4 IFL and 1 ZIIP (2+4+1=7) engines.

Name - This is the LPAR name.

Nbr - This is the LPAR number.

Virtual CPUs - This is the number of virtual CPUs this LPAR can access. For this example, there are 11 vCPUs defined on the CEC, the VSIVM4 LPAR has 3.

Typ - This is the CPU type - CP/IFL/ZIIP.

%Assigned/Total - This shows the total amount of time a CPU was assigned to the LPAR, inluding overhead. shows the total assigned time by CPU type, each LPAR name will show its own total time.
IE - Total assigned percentage for VSIVM4 for its IFL engines is currently 59.6%. (in teal)

Assigned Shares/LPAR/Weight - This is the total weight of the assignments for each virtual processor.
IE - The weight for the VSIVM4 engines is 200. (in green)

Assigned Shares/Weight/Pct - If not dedicated, this is the processing weight and percentage of the total assigned share.
IE - Total weight for IFL engines is 740, the weight for the VSIVM4 LPAR is 200 so its percent is 740/200=27.03% So VSIVM4 has 27.03% of the total assigned share. (in magenta)

Assigned Shares/VCPU Pct/SYS - This is the percent of the total CPUs of that type assigned to the Virtual CPUs in this LPAR.
IE - VSIVM4 has 3 IFL engines at 27.03%, each virtual CPU has 9.01%. (in orange)

Assigned Shares/VCPU Pct/CPU - This is the percentage of the CPU on the LPAR. IE - The box has 4 IFL engines, each VSIVM4 engine has 9.01% so total assigned share percent is 36.0% (4 x 9.01). (in red)

Thread Idle - When SMT is on, the IFL engines should show when the threads were idle. (This will show up for CP engines also, but it is not relevant.) If thread idle time is half of the assigned total, a core was assigned but only one thread was used. SMT may not be needed.

Entitled CPU Cnt - This shows how many IFLs this LPAR is entitled to. For each individual LPAR, this will be a percentage. This is a minimum target resource delivery.
IE - VSIVM4 is assigned 27.03% of the 4 IFLs (total physical IFLs), so a total 1.08% (27.03% x 4) or slightly over 1 IFL. (in brown)

Totals by Processor type: - This shows the physical totals for the box by processor type (on the report only). Note that unless dedicated, virtual cpus are shared over this amount of physical processors. So 11 virtual cpus (IFLs) are shared over 4 physical IFL processors.

NOTE: The Weight provided to an LPAR is divided into the virtual cpus (vcpus) of that LPAR so adding more vcpus to an LPAR dilutes the impact of the weight! The weight must change if more vcpus are added.

ESALPAR - Shows how the logical partition characteristics and processor utilization.

Weight/Polar - This shows the three different polarization levels. Notice that based on the weight, the number of virtual cpus and the number of physical cpus on the box, the polarization designation for each vcpu has been assgined - VHi (Vertical High), VMe (Vertical Medium) and VLo (Vertical Low). It is suggested that there should be no more than 1-2 VLo cores. More than that can cause PR/SM overhead.

ESALPMGS - Shows how the hardware/processing resources are distributed in the box.

CPU Type - This shows the different types of CPUs.

Ovhd/Mgmt - This shows the percentage of overhead/management overhead for the system. Currently on this system, the overhead is low, below 2%. If this rises into double digits, there could be too many vcpus defined. The ESALPARS report shows the totals for the day averaged every 15 minutes. (there is no ESALPMGS report specifically).

ESALPARS Example from another system - Shows the processor sharing configuration and utilization for each LPAR.

This CEC has 10 total physical IFLs that are 915.6% busy. That is over 9 physical processors are being utilized. This can cause issues to be over 90% busy. This is way more important for online (Linux) vs batch.
LPAR ZVMQA has 6 vcpus with a weight of 150 It is using 374.8% or almost 4 out of 6 CPUs worth of processing. That is more than its share.
LPAR ZVMPRD has 10 vcpus with a weight of 650. It is using 333.7% or a little over 3 out of 10 CPUs worth of processing. It could be lowered to 8 or 9 vcpus.