Mixed workload

Edit online

The relocation behavior of the transactional database workload was investigated when the source z/VM® system was under load resulting from several Linux™ guests running different workloads.

For this type of tests, the LPARs for z/VM systems were configured with 34 GiB of real storage and four CPs.

Figure 1 shows the environment used for the mixed workloads.

Figure 1. Mixed workload environment

A block diagram showing how LGR works in a mixed environment with two hosts

To generate CPU pressure two guests are running the Java™ workload and one guest is running the page cache file system I/O workload on the source z/VM system (Host 1). In addition, one guest is running an Oracle Database executing the transactional database workload which is driven by the external SwingBench client.

Details about the virtual system configurations are provided in Table 1.
Note: The relative share is adjusted for the number of virtual CPUs, such that every virtual CPU receives the same relative share.
Table 1. System parameters used for the mixed workload scenario
Guest VMSize # virt. CPUs rel. share Workload

A

4 GiB

1

100

Java

B

4 GiB

1

100

Java

C

4 GiB

1

100

fio - page cache

D

16 GiB

4

400

Oracle Database, running SwingBench OE workload

As usual with our tests, after some time (about seven minutes) the z/VM guest with the Oracle Database running the SwingBench OrderEntry workload is migrated to the target z/VM host (Host 1). It is shown how the live guest migration resolves the CPU pressure situation on the source z/VM system.