VMRM - managing workload peaks

Edit online

The measurement series discussed in this topic demonstrate the capabilities of VMRM in managing workload peaks in two scenarios. The first scenario examines the performance when Cognos® BI is the preferred workload, but a part of the CPU resources is also assigned to other tasks. The second scenario satisfies all CPU requests of Cognos BI, at the cost of other workloads.

Transaction throughput and response times

Two VMRM configurations are tested how they manage an abrupt workload (CPU load) peak, where all LPAR CPUs are fully utilized and which results in a CPU bound system.

Goal 1 - A chance for others: Whenever the system runs into such a described CPU constrained situation, Cognos BI should be the preferred workload. But other workloads still get a chance to perform some work. The VMRM CPU goals are set as follows:

Cognos BI CPU goal 70 / DayTrader CPU goal 25

Goal 2 - Cognos BI gets all: Whenever the system runs into such a described CPU constrained situation, Cognos BI should get all CPU resources it requires, even at the cost of other running workloads. The VMRM CPU goals are set as follows:

Cognos BI CPU goal 100 / DayTrader CPU goal 1

CPU load peak: The overall load starts unconstrained with the Cognos70 workload plus one DayTrader IFL in parallel for 10 minutes. Then the second DayTrader triplet and the DayTrader combo workloads are started. All DayTrader workloads together add up to the DayTrader50 load. From that point on, the LPAR CPUs are constrained for another 10 minutes and VMRM starts to manage the workloads according to their CPU goals. Afterwards, the DayTrader workloads are stopped except for one single DayTrader triplet and the system is unconstrained for the last 10 minutes.

The VMRM CPU goal importance is set to 100 for Cognos BI and is set to 1 for DayTrader for all measurements in this series.

VMRM managing workload peak – impact on Cognos BI throughput and response time time — Figure 1. VMRM managing workload peak – impact on Cognos BI throughput and response time

Observations: The Cognos BI transaction throughput is normalized against the unconstrained combined Cognos + DayTrader workload without the peak load. The green bar shows the Cognos BI transaction throughput and the red bar the response time.

The rightmost three bar pairs are the measurements including a 10 minute workload peak for the fair share and the two VMRM configurations (Goal 1 and Goal 2).

The fair share setup shows a clear throughput loss and increased response time.

The VMRM CPU goal configuration (70/25) called A chance for others minimizes the throughput loss compared to the fair share setup. There is also a much lower impact on the response time.

The VMRM CPU goal configuration (100/1) called Cognos BI gets all shows the same performance as the workload without CPU load peak.

Conclusion: The VMRM configurations match their goals and guarantee Cognos BI a defined transaction throughput level and response time when a sudden high peak load arises and leads to constraint CPU resources for the system.

The Cognos BI gets all configuration almost straightens out the CPU peak period and maintains the throughput as with an unconstrained CPU load.

VMRM seems to be very useful in protecting a preferred workload against other workloads running in parallel when the CPU resource becomes a bottleneck. For example, it achieves a much more efficient usage of CPU resources required for important workloads that run only in certain time slots.

VMRM CPU goal 1: a chance for others (70/25)

The VMRM CPU goals are set as follows for the workloads:

Cognos BI CPU goal 70 / DayTrader CPU goal 25 → high CPU goal for Cognos BI

Figure 2 shows the CPU load as used IFLs for the Cognos BI and the DayTrader guests during the peak and non-peak workload period, with:

the non-peak workload period: running from 00:00 to 08:00 and 19:00 to 28:00 minutes
the peak workload period: running from 08:00 to 19:00 minutes.

Figure 2. VMRM managing workload peak – Goal 1: CPU loads

Observations: The green areas show the CPU loads for the Cognos BI guests and the yellow area shows the load for the single DayTrader triplet1. These workloads are running all the time.

The red workload peak period in the middle of the figure is composed of DayTrader triplet2 + DayTrader combo.

In the beginning, eight LPAR CPUs are used and the system shows a high CPU utilization, but is still considered as unconstrained. During the workload peak period, all IFLs are used and the system is considered as CPU constrained.

Starting with the peak period, the increased DayTrader workloads are assigned additional CPU resources according to their current relative shares at the expense of the Cognos BI workload. This can be the default shares for the guests, or VMRM already adjusted the shares before. Thirty seconds later, a CP monitor sample interval completes and VMRM starts to adjust the relative shares towards the defined CPU goal. A few sample intervals later, the shares for the Cognos BI guests are upgraded and Cognos BI gets more CPU resources.

Figure 3 shows how VMRM modifies the relative shares for the guests.

Figure 3. VMRM managing CPU load peak – Goal 1: relative shares

Observations: The green lines show the relative shares for the most important Cognos BI guests (gateway and reports servers). The yellow, orange, and red lines show the relative shares for the DayTrader triplet WAS guests and the combo guest.

VMRM already begins to adjust shares even when the LPAR CPUs are not yet fully constrained. However, this happens apparently only for those guests that already have ongoing workload (Cognos BI and DayTrader triplet1). The relative shares for guests with no load (DayTrader triplet2 and combo) are untouched until the workload peak period starts.

The process of adjusting the shares in accordance to the CPU goals takes some time. The relative shares for all guests are kept at a lower level compared to the fair shares. But in relation, Cognos BI relative shares are higher than the DayTrader shares.

After the workload peak period ends, the Cognos BI guest shares are reduced. There are enough CPU resources available from that point on.

Conclusion: VMRM needs at least one CP monitor sample interval before it starts to adapt relative shares for the guests. With CPU goals below the maximum, the process of adapting relative shares takes longer and the guests with smaller shares still get enough CPU resources. This time period might shorten, when the less prioritized workloads already start with a lower relative share.

VMRM CPU goal 2: Cognos BI gets all (100/1)

The VMRM CPU goals are set as follows for the workloads:

Cognos BI CPU goal 100 / DayTrader CPU goal 1 → maximum CPU goal for Cognos BI

Figure 4 shows the CPU load [number of used IFLs] for the Cognos BI and the DayTrader guests during the peak and non-peak workload periods with:

the non-peak workload period: running from 00:00 to 08:00 and 19:00 to 28:00 minutes
the peak workload period: running from 08:00 to 19:00 minutes.

Figure 4. VMRM managing workload peak – Goal 2: CPU loads

Observations: The green areas show the CPU loads for the Cognos BI guests, and the yellow area shows the CPU the load for the single DayTrader triplet1. These workloads are running all the time.

The red workload peak period in the middle of the figure is composed of DayTrader triplet2 plus DayTrader combo.

In the beginning, around eight LPAR CPUs are used and the system shows a high CPU utilization, but is still considered as unconstrained. During the workload peak period, all IFLs are used and the system is considered as CPU constrained.

Starting with the peak period, the increased DayTrader workload gets the CPU resources according to their current relative shares. This can be the default shares for the guests, or VMRM already adjusted the shares before. But this time, the single DayTrader triplet1 has the most severe impact. Momentarily the CPU load for the DayTrader triplet1 goes down to 0.13 IFLs when the load peak started. Thirty seconds later, a CP monitor sample interval completes and VMRM starts to adjust the relative shares towards the defined CPU goal. This time, VMRM adjusts the workloads much faster to their goals. The Cognos BI workload shows a small dip for the CPU load at the beginning of the peak period, and over time, nearly shows no loss of CPU resources.

Figure 5 shows how VMRM modifies the relative shares for the guests.

Figure 5. VMRM peak workload – Goal 2: relative shares

Observations: The green lines show the relative shares for the most important Cognos BI guests (gateway and reports servers). The yellow and red lines show the relative shares for the DayTrader triplet WAS guests and the combo guest.

VMRM starts to adjust some shares before the workload peak is issued, even if the LPAR CPUs are not yet fully constrained. With the start of the workload peak period, VMRM begins to tightly increase the shares for the Cognos BI guests and they finally end up at 10000, which is the maximum relative share value.

The CPU shares for the DayTrader guests are kept at a very low level.

After the workload peak period ends, the CPU shares remain more or less unchanged from their latest values. However, there are enough CPU resources available for all workloads from that point on.

Conclusion: VMRM needs at least one CP monitor sample interval before it starts to adapt relative shares for the guests. With this maximum CPU goal for the Cognos BI workload, VMRM controls the relative shares in a completely different manner compared to more moderate CPU goals.

Note: Maximum CPU goals can lead to situations where competing workloads with very low goals get nearly no CPU resources.