Transactional WAS workload

Workload analysis

Figure 1 shows the relative throughput of the medium level transactional WAS workload when running 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 transactional WAS workload.

A general description of the elements shown in Figure 1 and Figure 2 is given in General description of relative throughput diagrams.

Observations:

Figure 1 shows that the degradation of the medium level transactional WAS workload relative throughput stayed relatively moderate until less than 112 GiB real memory were configured for z/VM. Particularly, with 64 GiB real memory, the throughput decline is more significant.

The tendency to remain unaffected by constraints of z/VM real memory was more pronounced for the throughput of the high level variant shown in Figure 2, particularly when small numbers of real CPUs were configured for z/VM.

By contrast, the influence of constraining the amount of real CPUs configured for z/VM while the amount of real memory configured for z/VM was kept constant, was much more significant at both workload levels. When the configured z/VM real memory was below 96 GiB, the relative throughput did not decline as sharply than above 96 GiB.

Conclusions:

The transactional WAS workload reacted more sensitively on z/VM CPU constraints as opposed to z/VM real memory constraints. It exhibited a nearly linear dependency of the throughput on the number of real CPUs configured for z/VM.

Opposed to that, the transactional WAS workload could tolerate even significant reductions of the amount of real memory configured for z/VM, with only small throughput degradations. This behavior was even more articulated for the high level transactional WAS workload, particularly when 15 or less real CPUs were configured for z/VM, and as long as the amount of real memory configured for z/VM stayed above 64 GiB. The throughput stayed almost constant until a certain level of memory overcommitment was reached, but beyond that level, the performance impact became severe. A possible explanation could be that in a z/VM real memory constrained situation, substantial portions of the Java™ heap cannot be kept constantly resident. When access to those portions is needed – for example during a Java garbage collection – z/VM needs to page in respective virtual memory regions, causing memory access latencies for the virtual system.

The gencon garbage collection policy that is per default applied by WebSphere® 8.5, might have attenuated these effects as it tends to less frequently perform passes over the complete Java heap. We will see later during the analysis of the Java workload, that use of the optthruput garbage collection policy might impose higher memory usage.

Overall, the transactional WAS workload seems to be a good candidate to be operated in conditions where z/VM real memory constraints exist, as long as the z/VM installation has a healthy paging subsystem available (see also section Memory usage and paging workload analysis for CID 64/20).

CPU usage analysis

Figure 3 shows the average CPU load for the medium level transactional WAS workload added up from all three workload components (IHS, WAS, and DB2), and 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 transactional WAS workload added up from all three workload components.

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 transactional WAS workload, the generated CPU load is almost independent from the amount of real memory configured for z/VM. Only when 20 CPUs were configured for z/VM, the CPU load generated by the transactional WAS workload decreased noticeably when 96 GiB or less were configured for z/VM.

On the other hand, when the number of CPUs configured for z/VM was constrained, the CPU load generated by the transactional WAS workload decreased nearly linearly with the number of CPUs configured for z/VM.

Conclusions:

As stated already in the workload analysis, the transactional WAS workload apparently is CPU bound.

A closer look into the CPU load behavior of the various components of the transactional WAS workload shows possible deviations of individual workload components.

CPU load distribution

Figure 5 shows the CPU load generated by the three components of the medium level transactional WAS workload.

Figure 6 shows the CPU load distribution generated by the three components of the high level transactional WAS workload.

Observations:

The three components of the transactional WAS workload exhibited similar CPU load characteristics. A significant impact of z/VM real memory constraints on the CPU load of the various components of the transactional WAS workload was only observed when 20 real CPUs were configured for z/VM, and was more pronounced for the high level workload.

Conclusions:

All three components of the transactional WAS workload suffered in a similar way when z/VM real memory and z/VM processing power was constrained.

An unexpected behavior was that for the medium level workload, and when z/VM was configured with 96 GiB real memory or less, the WAS CPU load increased as z/VM real memory was reduced.

Memory usage and paging workload analysis for CID 64/20

As with the database BI workload, here the detailed memory usage and workload analysis is only presented for the z/VM with a CID 64/20 configuration.

Figure 7 shows the average page distribution and the average page read rates for the medium level transactional WAS workload when running as part of the combined workload set in a z/VM CID 64/20 system configuration.

Figure 8 shows the average page distribution and the average page read rates for the high level transactional WAS workload.

A general description of the elements shown in Figure 7 and Figure 8 is given in General description of page distribution and page read rate diagrams. Note that the memory scale in Figure 7 and Figure 8 is different from that used in previous page distribution and page read diagrams.

Observations:

On average, for the IHS component, about one quarter of the instantiated memory was backed by resident memory, for the WAS component about one third was backed, and for the DB2® component only about 6 % were backed. Together, the three components of the transactional WAS workload occupied about 1.5 % of the z/VM DPA.

On average, the three components of the transactional WAS workload accounted for about one sixth of the z/VM page read operations. The averaged fractions of resident memory being paged in were about 0.4 % for the IHS component, 0.45 % for the medium level WAS component (0.34 % for the high level variant), and about 0.15 % for the DB2 component.

For the WAS component, the sum of the amounts of resident memory and stored memory was significantly higher than the instantiated memory, while for the other two components these numbers approximately match.

Within the transactional WAS workload, the WAS component exhibited the highest page read rate - about three times as high as each of the other workload components.

Conclusions:

The conclusions are presented separately for each workload component:

• IHS

  Previous experiences show that IHS usually exhibits moderate virtual memory requirements, using a few small application buffers accumulating to about 160 MiB, but no large buffers. In context of the DayTrader workload, it mainly acts as a gateway server, more or less passing through most incoming requests to the WAS server. In contrast to a typical web server environment, in this context the IHS server does not have to provide access to large amounts of web pages stored in files. Consequently, the use of the page cache is limited, as only few file accesses result. As a result, the memory footprint of the IHS server is small – around 500 MiB. Note that some of this memory usage is imposed by the Linux system itself.

• WAS

  From the three components of the transactional WAS workload, the WAS component is the most active virtual memory consumer. The resident fraction of the instantiated memory for the WAS component is also the largest of all components, indicating intense use of memory. This is also indicated by the highest page-in rate of all components.

  The dominant part of the virtual memory allocated in the WAS server is the Java heap with a fixed size of 2 GiB. Particularly within the high level workload, the instantiated memory of the WAS component is larger than the allocated Java heap, indicating that additional virtual memory is needed for elements outside of the Java heap.

  The actual usage of the memory from the Java heap can be estimated by inspecting Linux™ anonymous memory (as reported in the Linux proc file system under /proc/meminfo). The amount of Linux anonymous memory was 1.2 GiB for the medium level workload, and 1.6 GiB for the high level workload. This indicates that in both cases the Java heap was probably not expanded to its configured size. Nevertheless, workload processing was performed flawlessly even when only about half of the Java heap was kept resident, albeit with performance degradations.

  Furthermore, the use of the gencon garbage collection policy might have been a factor for the transactional WAS workload being able to tolerate the impact of moderate z/VM real memory constraints. This policy tries to reduce the amount of pages modified during a garbage collection.

• DB2

  It is assumed that DB2 allocates the dominant part of the virtual memory as Linux shared memory for database buffers. The amount of allocated shared memory is around 1.3 GiB for both workload levels (as reported by the Linux sar report).

  Within the DB2 virtual system, apparently all virtual memory is allocated – the amount of instantiated memory equals the virtual memory size. This might be attributed to DB2 using page-cached I/O that can cause large regions of virtual memory to be allocated. However, DB2 does not make the same intense use of memory as the other two components – the resident fraction of its instantiated memory is much smaller. At the same time, it causes a page-in rate similar to that of the IHS component. This might indicate that the memory usage of the DB2 component is less frequent, but similar to that of the IHS component.

  A factor influencing the DB2 virtual memory access behavior is that DB2 is the only component doing disk I/O, predominantly write operations. Page-cache based write operations imply that involved virtual memory pages are dirtied, which in turn invalidates corresponding previous copies of these pages that z/VM maintains in its paging store.

  Finally – as already observed with the database BI workload – a database is a highly sophisticated system that is able to attenuate the impacts of memory latencies by caching data in buffer pools, and by scheduling asynchronous operations.