Scale guests into memory overcommitment on z/VM 5.3

Edit online

In these tests we performed the same tests as in zvm52.html, but using z/VM® 5.3. We started with one database server guest and then added four more database server guests for a total of five guests. These five guests used all of the available physical memory. The number of workload driver users was adjusted to reach maximum throughput and the users were distributed evenly among the guests. The guests were scaled from five to ten. We strove to maintain maximum throughput while scaling the guests from five to ten.

Total throughput

Figure 1 shows the normalized transactional throughput for all guests when scaling the number of guests on z/VM 5.3 into the memory overcommitment.

Figure 1. Normalized transactional throughput for scaling the number of guests on z/VM 5.3

lm06

Observations

Figure 1 shows the effect of memory overcommitment on throughput with a near linear decrease. At ten guests, throughput has deceased by slightly more than 40%.

CPU utilization

Figure 2 shows the CPU utilization of each guest and the total CPU utilization for the z/VM LPAR for the ten CPUs assigned.

Figure 2. Total CPU utilization per number of guests

lm07

Observations

Figure 2 shows the effect of memory overcommitment on CPU utilization. Adding additional guests results in more z/VM overhead. According to the throughput behavior shown in Figure 1, as more guests are added, there is a near linear decrease in CPU utilization for the guests. The z/VM overhead starts to increase significantly at nine guests.

Page location

Figure 3 shows the location of page frames associated with guests. The values are a sum of the location of the page frames for each individual guest.

Figure 3. Page location - guest scaling on z/VM 5.3

lm08

Observations

Figure 3 shows the location of pages in the system as guests are increased from five to ten. The most interesting curve is the utilization of the paging space on DASD. Its increase is near linear at a constant slope. At ten guests there are more pages on DASD than in memory.

Page movement

Figure 4 shows the relation of the memory overcommitment on the page movement rate to the various destinations.

Figure 4. Page movement - guest scaling on z/VM 5.3

lm09

Observations

As guests are scaled from five to ten, the page movement rates from main storage to XSTOR and from XSTOR to DASD increase. The movement rates continue to increase all the way up to ten guests.

Conclusion

The total system memory of 80 GB (20,971,520 pages) is overcommitted as follows:

Table 1. Overcommitted system memory - z/VM 5.3
Number of Guests Pages Not in Memory (= paged out) Real Overcommit (pages used: memory) - 1 Planned Overcommit (virtual : physical) - 1 Throughput % From Baseline
XSTOR DASD % % %
5 263193 0 1 0 baseline
6 1031469 5905366 33 20 82
7 1030564 11152384 58 40 77
8 1033732 16862208 85 60 70
9 1034246 21728256 109 80 65
10 1034667 25014272 124 100 58

At six guests, the throughput has decreased to 82% of the five guests' value. With the addition of more guests, throughput declines at an almost linear rate and at ten guests, throughput has decreased to 58%. As guests are added, z/VM 5.3 overhead also increases. This time the real overcommitment is 24% higher than the planned overcommitment. It appears that the paging algorithm for z/VM 5.3 decides to move pages out to DASD more often, which seems to be an advantage for this workload.