VMRM parameters

Edit online

For the second test scenario, the z/VM® setup was modified to enable z/VM Resource Manager (VMRM). The Cognos® BI and the DayTrader workloads were put into separate VMRM workload groups.

Then a high velocity target for CPU is defined for Cognos BI, and a low one is defined for the DayTrader (see sample definition in z/VM Resource Manager (VMRM).

The first measurement series helps to understand the influence of the VMRM parameters and shows how they impact the transaction throughputs and response times for both workloads. Especially these parameters were of interest:

CP Monitor facility sample interval
VMRM CPU goal importance
VMRM CPU goals for the workloads

Finally, two VMRM configurations are selected to study the management of a sudden workload peak period resulting in a time frame with a CPU constraint for the SUT.

CP monitor sample interval

VMRM requires CP monitor sample data in order to monitor the performance of a virtual machine. VMRM starts sample monitoring, if it is not active. The default CP monitor sample interval is 60 seconds. Shorter sample intervals are tested to reduce the reaction time for changed CPU load situations and their influence on the Cognos BI transaction throughput and response time.

Observations: The CP monitor sample interval is scaled down from 60 to 6 seconds. The dark bars show the transaction throughput for Cognos BI and the light bars the corresponding response time. The measurements with 15 and 30 seconds for the sample interval show around 6% higher throughput numbers and more than 6% shorter response times.

Conclusion: The default CP monitor sample is 60 seconds, which is a long time for a resource management interval. To shorten the time to react on workload load peaks, a smaller sample interval has been chosen, which improves throughput and response times. A too short interval can introduce unnecessary overhead and degrades the performance. An interval value between 15 and 30 seconds shows the best behavior in our environment. For all other VMRM measurement series, a sample interval of 30 seconds has been chosen.

Goal importance

The VMRM goal importance is an integer number from 1 to 10. The higher the number, the more important is the goal for the workload to be managed.

The following CPU goal importance combinations for the workloads are tested:

Cognos BI importance 10 / DayTrader importance 1 → highest importance for Cognos BI
Cognos BI importance 8 / DayTrader importance 3 → high importance for Cognos BI
Cognos BI importance 5 / DayTrader importance 5 → same importance for both workloads

The workload CPU load levels for this measurement series are Cognos70 + DayTrader50 resulting in a constrained LPAR CPU load. The VMRM CPU goal was set 70 for Cognos BI and 25 for DayTrader for all measurements in this series.

Figure 2 shows the Cognos BI and DayTrader transactions when scaling the goal importance.

Figure 2. VMRM parameters – influence of the goal importance

Observations: There is a slight advantage for the 10/1 CPU goal importance for the Cognos BI workload. However, the impact of this parameter is not very relevant for the tested scenarios.

Conclusion: The 10/1 CPU goal importance (highest priority for Cognos BI) is chosen for the next VMRM measurements. This goal importance also matches best the objective to privilege the Cognos BI workload over all other workloads.

Probably this parameter becomes more important when there are more than two CPU goals and workload groups defined.

Workload CPU goals

The VMRM CPU goals can be an integer number from 1 to 100. The number specifies the percentage of time that a workload should receive CPU resources.

The following CPU goal combinations for the workloads were tested:

Cognos BI CPU goal 60 / DayTrader CPU goal 25 → moderate CPU goal for Cognos BI
Cognos BI CPU goal 70 / DayTrader CPU goal 25 → high CPU goal for Cognos BI
Cognos BI CPU goal 80 / DayTrader CPU goal 25 → high CPU goal for Cognos BI
Cognos BI CPU goal 100 / DayTrader CPU goal 1 → maximum CPU goal for Cognos BI

The workload CPU load levels are set to Cognos70 + DayTrader50 / DayTrader75 resulting in a constrained LPAR CPU. The VMRM CPU goal importance is set to 100 for Cognos BI and to 1 for DayTrader for all measurements in this series.

Figure 3. VMRM parameters – CPU goals: Cognos BI transaction throughput

Observations: The Cognos BI transaction throughput is normalized against the fair share mixed workload scenario Cognos70 + DayTrader50. The leftmost single bar shows the transaction throughput for Cognos70 running as a single workload on the system without any CPU constraint. All other mixed scenarios run in a constraint CPU environment.

In the fair share scenario, the transaction throughput decreases due to the parallel DayTrader workloads running. The higher the pressure from the DayTrader workloads (DayTrader75), the greater is the impact on the Cognos BI workload.

The four rightmost bar pairs show the transaction throughputs for the VMRM scenarios with the different CPU goal combinations. The moderate and high CPU goals for Cognos BI score a higher transaction throughput compared to the fair share scenario. The maximum CPU goal shows the best throughput getting closer to the single Cognos BI only throughput.

Even with a higher DayTrader load level (DayTrader75), the Cognos BI transaction throughput stays at the same level as with a lower DayTrader50 load level for a certain CPU goal combination.

Figure 4. VMRM parameters – CPU goals: Cognos BI response times

Observations: The leftmost single bar shows the best Cognos BI transaction response time for Cognos70, running as a single workload on the system without any CPU constraint. All other mixed scenarios run in a constraint CPU environment.

The fair share scenario shows the highest response times due to the parallel DayTrader workloads running. The higher the pressure from the DayTrader workloads (DayTrader75), the higher is the response time for the Cognos BI transactions.

The four rightmost bar pairs show the response times for the VMRM scenarios with different CPU goal combinations. The moderate and high CPU goals for Cognos BI show better response times compared to the fair share scenario. With the maximum CPU goal, the response time is getting closer to the response time of the single Cognos70 workload.

Even with a higher DayTrader load level (DayTrader75), the Cognos BI transaction response times stay at the same level as with a lower DayTrader50 load level for a certain CPU goal.

Conclusion: In all VMRM configurations (moderate, high and maximum), the Cognos BI workload is preferred over the DayTrader workload and scores higher throughput numbers for Cognos BI compared to the fair share setup. The behavior for response times is similar.

The maximum CPU goal results in the best transaction throughput and response time of all VMRM configurations. This meets the expectation of this goal to give Cognos BI the highest priority. But this setup bears the risk that the DayTrader workloads get nearly no CPU resources and may run into a time-out. The SUT was set up to avoid such a scenario by assigning three CPUs more to z/VM than the Cognos BI workload would use at its maximum load level. But in a more constrained environment with seven CPUs for example, Cognos BI would require all CPUs and the remaining CPU resources might become critical for the lower prioritized workloads.

Another important aspect is that the Cognos BI transaction throughput and response time keep its levels regardless of the DayTrader CPU load level. The relative shares are adjusted, so that the CPU goal is met whatever the pressure from the competing workload is. This demonstrates how useful VMRM really is to guarantee a certain load level for the Cognos BI workload.

The definition of a CPU goal is the most important tuning parameter for the VMRM CPU management capability.

CPU loads for some workload CPU goal combinations

Figure 5 shows the Cognos BI and different DayTrader CPU load total percentages for the system. The mixed workload scenario Cognos70 + DayTrader50 is used for all CPU goal combinations.

Figure 5. VMRM CPU goals – CPU loads for some VMRM CPU goal combinations

Observations: The five bars show the stacked CPU load percentages for the Cognos BI and DayTrader workloads. The mixed workload scenario Cognos70 + DayTrader50 results in a CPU constrained system. The total system CPU load percentage is at 100% for all VMRM CPU goal combinations.

For the three leftmost CPU goal combinations, the Cognos BI goal was scaled from 60 to 80, and DayTrader was kept at 25. The Cognos BI CPU percentages slightly increases to 60%. With the CPU goal combination 70/40, the DayTrader workloads receive a higher CPU goal. The Cognos BI CPU percentage decreases from around 60% to 50% compared to the CPU goal combination 70/25.

The rightmost bar shows the maximum CPU goal 100/1 in favor to Cognos BI. In this case, Cognos BI gets more than 65% of the CPU resources. Keep in mind that the maximum CPU percentage for the CPU load level Cognos70 would be 70%.

Conclusion: This measurement series shows the influence on the assignment of CPU resources for some different CPU goal combinations. Varying CPU goal combinations allow a fine-tuning for the assignment of CPU resources that a particular workload should receive in a CPU constraint system .

Notice that a CPU goal combination of 70/40 does not mean Cognos BI gets 70% of the available CPU resources. Furthermore this is the percentage of time that the workload should receive CPU resources when it is ready to consume them. This results in 50% of the available CPU resources in this case.