Various workloads - number of memory passes and amount of data transferred
To keep the quiesce time (the time during which a guest is stopped during the relocation process) as small as possible, the live guest relocation process performed by z/VM® is organized into a number of passes.
During each pass, z/VM scans the memory of the z/VM guest for changed pages, and then transfers these changed pages from the source to the target z/VM system.
For the first pass the changed pages are all those pages that were so far written to by the programs (including the operating system) running within the z/VM guest.
During the intermediate passes (all but the last two ones), the guest virtual system on the source z/VM system continues its work, resulting in new memory changes. z/VM determines the pages that were changed during a particular path, and transfers these during the subsequent pass.
During the last two passes (named the "penultimate pass" and the "final pass" in z/VM documentation) the z/VM guest is effectively stopped, such that no new memory changes can occur from programs being executed. However, there still may be pending I/O operations that need to be completed and the pages targeted by these I/O operations also need to be transferred. For that reason, two passes are performed while the guest is stopped.
Figure 1 shows how the number of pages transferred during various passes of the relocation process scales when different kinds of workloads run within the relocated z/VM guest.
The results shown in Figure 1 correlate with the results from various workload that were previously discussed:
- The reference Reference workload - Java workload
- The maximum throughput page cache file system I/O workload in File system I/O workload – scaling the fio throughput for page cache I/O (rightmost in Figure 1)
- The maximum throughput direct I/O file system I/O workload inFile system I/O workload - scaling the fio throughput for direct I/O (rightmost in Figure 1)
- The transactional database workload in Transactional database workload - scaling the Linux guest size and Oracle Database target memory (leftmost in Figure 1)
In all these cases arranged in Figure 1, the virtual system size is 4 GiB (or 1024 k pages), and the size of the Oracle Database memory target is 1616MiB.