Number of Logical CPs Defined for an LPAR

The IBM Best Practice recommendation is to not configure all of the available logical CPs to each partition. Rather, we recommend the number of logical CPs defined be equal to the number of logical required to satisfy the relative weight of the LPAR, plus 1-2 additional logical CPs.

There are multiple reasons for this:

1. LPAR Busy value displayed on an online monitor are relative to the number of logical CPs so many parked logical CPs distorts the metric and its value. For instance lets say the LPAR gets 4.7 CPs by weight and they have 5 logicals. They are using 4.4 CPs, the LPAR busy should be 88% busy. If this LPAR is defined on a 732 way with 32 logical CPs then the LPAR on the monitors will look like 12% busy. Users of the monitor are going to think there is plenty of capacity. But really the LPAR is using 4.4/4.7 = 93.6% of its allowed weight. Any automation is also going to have to know to recalculate the LPAR busy to an actual value.

2. The LPAR time slice is sensitive to the number of logical CPs and having more logicals may drive your time slice to a smaller interval for your vertical medium and vertical low logical processors

3. Any kind of massive CPU loop type problem with a lot of Dispatchable Units would be able to schedule against many more logicals. The number of logical is an upper gate on the disruption of this. In such a situation the impact on the rolling 4hr average would be much greater.

4. There are z/OS operations such as Quiesce which have to be performed against all logicals even ones which are 100% parked.

5. Work will run most efficiently if you run within your defined weight, using vertical highs and vertical mediums to support the workload and avoid use of vertical lows except for occasional workload spikes. If the workload in the LPAR relies upon vertical lows for throughput you may want to change the weight to match actual usage.

6. System resources are consumed, such as control blocks, storage (like for trace buffers), for each logical CP. Some of these control blocks are in 16M storage. Additional logical CPs can cause impacts to be seen in SVC dumping, SMF 70 records get longer, CPUMF functions are increased as they have to report on every logical, command response displays are longer, etc.