Heapsize for the 64-bit Java Virtual Machine

Edit online

To compare the performance of 64-bit WebSphere® to 31-bit WebSphere, an attempt was made to identify the optimal percentage of available memory to dedicate to the JVM heap for the workload.

A starting value of 50% of available memory was used, and the value was increased to 80%. Throughput, workload operations per second, and CPU utilization are recorded. Response times are also recorded as another possible measure of optimization.

The data is collected at two different workload submission rates, 300 and 500, with either four or eight CPUs, and with either 4 GB or 8 GB of memory configured on the WebSphere LPAR. Within each submission rate, WebSphere's JVM minimum and maximum heap settings are set to identical values corresponding to different percentages of the LPAR's configured memory.

To analyze the results, two comparisons were done:

Throughput and CPU utilization

The results for throughput and CPU utilization are summarized in Table 1, and displayed graphically in Figure 1.
Table 1. Heapsize studies of 64-bit WebSphere: throughput, CPU load, and response time using workload submission rate 300 and 500, and different JVM heap percentages of total available memory
Workload submission rate Number of CPUs Memory in GB Heap percentage of memory Normalized workload throughput CPU utilization Response time (ms)
300 4 4 33% 100% 346% 349
300 4 4 60% 100% 322% 334
300 4 4 69% 100% 315% 343
300 4 4 75% 100% 333% 359
500 8 8 59% 165% 633% 740
500 8 8 70% 166% 542% 751
500 8 8 75% 165% 554% 706
500 8 8 80% 165% 573% 706
Figure 1. Heap size studies of 64-bit WebSphere: throughput and CPU load at workload submission rate 300 and 500, and different JVM heap percentages of total available memory
Bar graph of heap size study
Observation

The measures of throughput are generally fairly constant with this workload. The CPU utilization generally is lowest at values between 68% and 75% of the available memory of the processor. When memory of 8 GB is dedicated to the Linux® system, the 75% of available memory value provides the lowest CPU utilization. When memory of 4 GB is dedicated to the Linux System, the optimal heap size tends to be closer to the 70% of available memory value.

Conclusion

The throughput seems to be dependent only on the submission rate. When sufficient resources are available to support a certain submission rate, more resources do not increase the throughput. The CPU utilization seems to be a better parameter to determine the best JVM heap size. For this workload, a value of between 70% and 75% from the main memory is the best, where smaller heap sizes are better for smaller memory sizes.

CPU utilization and response times

Another parameter to observe is the response time between the simulated Web operation, such as a purchase or a browse operation, and the turnaround time of the request from the WebSphere system. The results for CPU utilization and response time are summarized in Table 1 and displayed graphically in Figure 2. Response times are shown as a bar chart, and unlike throughput measures, smaller response time values are considered optimal.

Figure 2. CPU utilization and corresponding average response times at different JVM heap percentages
Bar graph of CPU utilization
Observation

In this workload, the CPU utilization is lowest, and the response times shortest, at between 68% and 75% of the available memory of the processor. Mainly it seems that the response time follows the CPU utilization.

Conclusion

The correlation of response time with CPU utilization when scaling the Java™ heap size indicates that both have a common dependency. A larger heap can avoid some garbage collection, which leads to a decreasing CPU utilization. And it seems that a heap that is too large increases the CPU utilization (user space CPU), probably caused by an increased garbage collection duration that degrades performance when compared with a smaller heap size. For the other studies with 8 GB memory, a heap size of 75%, which is 6144 MB, was used.