Java workload
This section describes the analysis of the test results from processing the Java workload under various constrained z/VM® configurations.
Workload analysis
Figure 1 shows the relative throughput of the medium level Java™ workload when processed as part of the combined workload set within a variety of differently constrained z/VM configurations.
Figure 2 shows the relative throughput of the high level Java workload.
A general description of the elements shown in Figure 1 and Figure 2 is given in General description of relative throughput diagrams.
Observations for both levels of the Java workload:
When running during the reference execution, the relative throughput of the medium level Java workload was about 53 % of that of the high level workload.
When less z/VM real memory was configured, the influence on the throughput of the Java workload was mostly insignificant as long as 112 GiB real memory or more were configured for z/VM. In these cases, when 15 or more real CPUs were configured for z/VM, the throughput was even slightly higher than that achieved during the reference execution. However, in any case, the throughput decreased considerably when 96 GiB real memory or less were configured for z/VM. The decrease was more pronounced for the medium level workload.
The throughput of the Java workload was only slightly affected by the number of real CPUs configured for z/VM, when 15 or more real CPUs were configured. When 10 or less real CPUs were configured for z/VM, the throughput declined sharply, with the decline being larger when the number of real CPUs was reduced from 10 to 5.
Conclusions for both levels of the Java workload:
The Java workload seems likewise to be impacted by z/VM real CPU and real memory constraints. While the impact stayed low, as long as 112 GiB real memory or more, and 15 real CPUs or more, were configured for z/VM, it became significant as the resources were configured below these limits.
On the positive side, when z/VM real CPU and real memory constraints were small, the Java workload could apparently profit, whereas other workloads were more seriously impacted by these small constraints.
Overall, the Java workload seems capable to tolerate moderate resource constraints at the z/VM level, but the throughput deteriorates when the resource constraints exceed a certain level. This limit needs to be detected by performance analysis. In our environment, we found that 112 GiB real memory or more, and 15 real CPUs or more need to be configured for z/VM in order to retain acceptable throughput of the Java workload.
CPU usage analysis
Figure 3 shows the average CPU load for the medium level Java workload when running as part of the combined workload set within a variety of differently constrained z/VM configurations.
Figure 4 shows the average CPU load for the high level Java workload.
A general description of the elements shown in Figure 3 and Figure 4 is given in General description of relative throughput diagrams, except that in Figure 3 and Figure 4 CPU load is presented instead of throughput.
Observations for both levels of the Java workload:
The CPU load generated by the Java workload was almost independent from the amount of z/VM real memory, when 112 GiB real memory or more were configured for z/VM. When the amount of real memory configured for z/VM was below 112 GiB, a small decline of the CPU load resulted.
The amount of real CPUs configured for z/VM had almost no influence on the CPU load generated by the Java workload, when 15 or more real CPUs were configured for z/VM, but declined more than linearly as less than 15 real CPUs were configured for z/VM. This effect was even more significant for the medium level workload.
Conclusions for both levels of the Java workload:
As already diagnosed in the Workload analysis, when running as part of the combined workload set, the Java workload reacted lightly and in some cases even positively on small z/VM resource constraints, but reacted strongly, as the z/VM resource constraints became severe.
Consequently, when executing a Java workload within a z/VM environment where occasional real resource constraints are possible, the break point of the performance of the Java workload should be determined by an initial performance analysis, and during later processing should be monitored in order to not exceed that break point. If the break point is reached or exceeded, the temporary addition of real CPUs to the z/VM configuration might help to overcome a Java workload throughput degradation.
Memory usage and paging workload analysis for CID 64/20
As usual, the detailed memory usage and workload analysis is only presented for the z/VM configuration with 64 GiB real memory and 20 real CPUs (CID 64/20).
Figure 5 shows the average page distribution and the average page read rate for both levels of the Java workload when executed as part of the combined workload set, with z/VM running as a CID 64/20 configuration.
A general description of the elements shown in Figure 5 is given in General description of page distribution and page read rate diagrams. Note that the memory scale in Figure 5 is different from that used in previous page distribution and page read diagrams.
Observations:
Both levels of the Java workload exhibited rather large amounts of instantiated memory that were mostly backed by resident memory. For the medium level workload, on average about 91 % of the instantiated memory was backed by resident memory, and for the high level workload this percentage was 85 %. These resident memory sizes accounted for 5 % (medium level) and 4.6 % (high level) of the z/VM DPA. In both cases, the sum of resident memory and stored memory is much larger than instantiated memory, indicating that a large number of pages is kept in both places, real memory and on paging storage.
The Java workload averaged at about 5.7 % (medium level) and 17.2 % (high level) of the z/VM page read operations. The averaged fractions of resident memory being paged in were about 0.15 % for the medium level, and about 0.5 % for the high level workload.
Conclusions:
The high fractions of resident memory indicate that the Java workload makes intense and widespread use of virtual memory. This observation is confirmed by the comparatively high page-in rates that – combined for both workload levels – make up for about a quarter of the total z/VM page read rate.
As detailed in the workload analysis, workload processing of the Java workload within CID 64/20 is degraded by about 45 % (medium level) and 26 % (high level). Apparently, the virtual system that is processing the high level Java workload configured with two virtual CPUs, is less affected by z/VM memory resource constraints. This could indicate that the availability of the second virtual processor is not only beneficial for achieving a higher throughput (about twice as high as that of the medium level workload), but also does help to attenuate z/VM memory resource constraints.
With respect to the allocation and use of virtual memory the dominant part is the Java heap size of 3.2 GiB. The optthruput garbage collection policy applied for this workload is known to cause much higher and more widespread memory accesses during garbage collection than the gencon garbage collection policy applied for the transactional WAS workload.