/ Capacity planning analysis of a 32-bit vs. 64-bit IBM Java VM ~ Java EE Support Patterns

2.13.2011

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

3 comments:

Interesting article. Did you by any chance experiment with IBM's 64-bit JVM compressed references to see if it made any difference?

Using compressed references should make a significant difference and reduce the memory footprint again to values which are comparable to the 32-bit JDK, see
http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/topic/com.ibm.java.doc.user.aix64.60/user/garbage_compressed_refs.html

"If you specify the -Xnocompressedrefs command-line option, the IBM SDK for Java 64-bit stores object references as 64-bit values. If you specify the -Xcompressedrefs command-line option, object references are stored as 32-bit representation, which reduces the 64-bit object size to be the same as a 32-bit object."

Thanks for your comments and recommendations,

You are correct, I will update the article with the recommendation. I'm also planning another article that will highlight and measures the improvements asosciated with the compressed references feature.

Thanks.
P-H

Post a Comment