Capacity planning analysis of a 32-bit vs. 64-bit IBM Java VM

This post provides a Java memory footprint comparison analysis between a Weblogic Integration 9.2 application running on an IBM SDK 32-bit VM vs. an IBM SDK 64-bit VM.

We will demonstrate how proper analysis and understanding of the impact is required before you decide to upgrade your application to a 64-bit VM.

Environment specifications

·         Java EE server: Weblogic Integration 9.2 MP2 (WLI)

·         OS: AIX 5.3 TL9

·         JDK: Java version: 1.5.0 SR6, IBM VM

·         RDBMS: Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit Production

·         Platform type: Middle tier  - Order Provisioning System

Background and objectives

Following a recent capacity planning exercise and production performance metric analysis, it was decided to explore as a POC (proof of concept) the option to upgrade our application from a 32-bit to a 64-bit VM.

Objectives:

·         Identify any application impact and/or code change required

·         Identify any impact on existing Java Heap footprint

·         Identify any impact on existing Native Heap footprint

·         Identify any impact on CPU utilization or other negative side effect

Java Heap analysis

The Java Heap memory footprint was captured during the load test cycles using the JConsole monitoring tool.

32-bit Java Heap footprint

64-bit Java Heap footprint

The 64-bit Java Heap footprint is clear showing an increase of ~ 400 MB which represents a 45% increase vs. the 32-bit VM for the exact same application and peak load

Native Heap analysis

The Native Heap memory footprint was captured during the load test cycles using the svmon command:

## Native Heap segment name for 32-bit svmon is: working storage.

svmon -P <java process pid> -m -r | grep 'working storage'

617783         3 work working storage              s  63206     0    2 63208

162449         4 work working storage              s  31117     0   38 31155

593762         f work working storage               s  238          0    0   238
...................................................................................................

Footprint calculation (segment 3 & 4 only): (63206 + 31117) x 4KB pages / 1024 = ~ 368 MB

## Native Heap segment name for 64it svmon is: work text data BSS heap

svmon -P <java process pid> -m -r | grep 'work text data BSS heap'

129a5f        11 work text data BSS heap           s  64352     0    0 64352

1f5a68        12 work text data BSS heap           s  24537     0    0 24537
......................................................................................................

Footprint calculation (segment 11 & 12): (64352 + 24537) x 4KB pages / 1024 = ~ 347MB

The differences of Native Heap memory footprint observed between the 32-bit VM and 64-bit VM were non significant.

Comparison matrix

Analysis	32-bit VM	64-bit VM	Delta +/- %
Application code	n/a	No code change	No code change
Java Heap capacity	1.75 GB	1.75 GB	Equal capacity but increased capacity potential
Java Heap footprint	0.9 GB (~50%)	1.3 GB (~ 75%)	+ 45%
Native Heap capacity	768 MB	Unbounded	Increased capacity
Native Heap footprint	368 MB	347 MB	Non significant
Full GC process	4-5 times per 5 min	8-10 times per 5 min	+100%
CPU load	20%	30%	+50%

Facts derivation:

·         No application code change required

·         The Java Heap with 64-bit VM has increased by 45%

·         The Native Heap is mainly left unchanged

·         The GC occurrences has almost doubled and correlate with the increased Java Heap footprint

·         The CPU utilization has increased by 50% and correlate with the GC occurrences increase

* Please note that the increased Java Heap footprint was expected since each Java Heap object occupies more space in a 64-bit VM *

Conclusion and recommendations

Our testing strategy clearly demonstrated that upgrading an application from a 32-bit to a 64-bit VM can cause some impact to the existing memory and performance figures. The increased Java Heap footprint along with GC and CPU proves that proper capacity planning is a must in order to identify any vertical scaling of your application server and/or hardware upgrade requirement.

That being said, the main benefit of a 64-bit VM is a huge capacity potential for both Java Heap and Native Heap. Applications that rely heavily on memory data caching along with fast hardware will clearly benefit from it.

Our final recommendations can be summarized as per below:

·         Upgrading from a 32-bit to 64-bit VM is not that straightforward and requires proper capacity planning and impact analysis

·         Java EE applications that do not require huge allocation of Java Heap and/or Native Heap should not systemically upgrade to a 64-bit VM

·         Before upgrading to a 64-bit VM, you should first revisit your existing application memory footprint and identify any reduction opportunity

Posted in: IBM AIX,IBM JVM,Oracle Weblogic