Summary

The performance behavior of various kinds of workloads was evaluated while the virtual system running the workload was relocated.

Variations of the workload parameters were inspected with respect to their influence on the live guest relocation process. The objective was to analyze the characteristics of the different workloads in regard to their relocation behavior, especially with respect to the critical quiesce times during which the virtual machine is no longer dispatched.

Another important aspect was how the workload level influences the relocation times. The aim was to provide an impression which workloads are expected to get relocated easily, which workloads might have an higher impact on the relocation process, and where it might make sense to consider additional optimization steps to mitigate that.

The Java™ workload was found to have the longest relocation times and highest effort required to transfer memory pages, due to the high memory access rates and a widespread memory access distribution which are typical for Java workloads. Objects are frequently created and released on the heap, and a garbage collection process periodically recovers the memory from the released objects.

With direct I/O, data is directly written to the disk devices, and bypasses the Linux page cache.

In both cases, the throughput rate of the written data was scaled. Using page cache I/O causes higher total relocation and quiesce times with increasing I/O throughput. However, both times are significantly lower than those observed for the Java workload, and with a value below two seconds comparatively small for a 4 GiB guest. The amount of pages to be transferred to the new guest in the page cache case scales with the throughput, while it is constant for the direct I/O case, which explains the shorter quiesce times.

The transactional database workload was found to be a candidate that is easy to relocate. The relocation times scale linearly with the database memory size, with the important quiesce times scaling with a much lower factor. The 4 GiB guest with a database memory of 1.6 GiB had a quiesce time below 1 second, and even a guest with a 22 GiB memory size has a quiesce time below 5 seconds.

At the user level the downtime of the servers during the quiesce time might cause timeouts which might cause the ongoing transaction to fail. In all our relocation tests, Linux and application recovery with the guests was transparent, and processing continued without reporting errors (except time shifts).

Finally it could be very clearly shown how the workloads in a totally overloaded system could be improved by relocating one guest to another z/VM® node in the cluster. With the relocation the CPU steal times on the database guests was reduced from about 1.5 CPUs to 0.1 CPUs.