z/VM guest statistics: working set size and CPU overhead

During our performance tests, we monitored and recorded the z/VM guest statistics working set size and CPU overhead.

Beside the view on the virtual resources, another view on the system is what is physically allocated and what the costs are of all the virtualization. Concerning the CPUs, we saw what happens when the available physical CPUs are exhausted with five triplets. The total throughput stays nearly constant, even though there must be some overhead because of dispatching unique resources to the waiting guests. Concerning the memory, there are a lot of optimizations implemented in z/VM® to keep the allocation small. This can be easily verified looking at the working set size (WSS), which represents the amount of memory really allocated from one guest (see Table 1). Additionally, it shows the ratio of total CPU to Virtual CPU spent for one guest. The total CPU consists of the Virtual CPU (where the guest is using CPU) and the CPU used from CP to manage that guest and its virtual devices.

Table 1. Working set size and CP cost per guest
Guest WSS (MB) CPU Total/Virtual
LNUDB1 398 1.04
LNUDB2 400 1.04
LNUDB3 390 1.04
LNUDB4 390 1.06
LNUDB5 393 1.07
LNWAS1 1434 1.07
LNWAS2 1442 1.07
LNWAS3 1443 1.07
LNWAS4 1433 1.12
LNWAS5 1445 1.12
LNWEB1 159 1.22
LNWEB2 169 1.22
LNWEB3 162 1.23
LNWEB4 160 1.23
LNWEB5 163 1.22
Total: 9,981 MB Average: 1.12

Observations

The WSS and the overhead depends heavily on the type of server. The lowest amount of memory is used by the Web server, the next lowest is the database server with more than twice the memory, and finally, the WebSphere® Application Server with about 1.5 GB, which is still less than the maximum possible value of 2 GB. The ranking for the overhead is quite different. Here the database server and the WebSphere Application Server are very similar and are much lower than the Web server.

Conclusions

The reason for the small WSS size of the Web server is that it 'only' transmits the requests coming from the external network, it does no disk I/O. On the WebSphere Application Server the Java™ heap is set up to use 1 GB and it seems to be really used, while the database requires memory for buffer pools and disk I/O, which uses the page cache. The reason for the high CP overhead from the Web server is expected to be the access to the physical network interface, which generates interrupts, requiring z/VM to intercept. Using z/VM guest LAN has a much lower impact, shown by the overhead from the database server and the WebSphere Application Server, even though the WebSphere Application Server has more CPUs than the others. Therefore, the usage of the z/VM guest LAN could be highly recommended, not only because the setup is so easy, but because it reduces the overhead significantly.

Actually, we did not really overcommit the memory. This shows that z/VM is very efficient in managing guest memory pages.