JVM performance tuning
Overview
- Determine the caching strategy and configure the caches.
- Understand WAS recommended settings for JVM tuning.
- Understand debugging techniques
- Understand the Generational Concurrent Garbage Collector.
Tune the JVM
When a JVM is started, it obtains a large area of memory from the underlying operating system. This area is called the heap, and Java performs its own memory management by allocating areas of the heap as memory is needed by the process.
To reduce complexity, tune memory in stages. First, turn off both WebSphere's dynamic caching and the prepared statement cache; then turn them on one at a time.
If you use Sales Center, and you send large BOD files; enlarge the maximum heap size to prevent memory errors.
The garbage collector policy is Generational Concurrent Garbage Collector, -Xgcpolicy:gencon. Typically, you do not need to change this garbage collector policy.
To start, specify a value for -Xmns, the minimum new area size, approximately 20% of the maximum heap size specified by the -Xmx property. Ensure that this value is no larger than 512 MB. Specify a value for -Xmnx, the maximum new area size, that is about 40% of the maximum heap size.
Ensure that this value is no larger than 1024 MB.
To set the maximum heap size, see Tune the IBM virtual machine for Java.
Use verbose garbage collection information to determine the amount of free memory in the heap. Generally, less than 40% free memory causes the garbage collection overhead to increase and performance to be negatively affected.
To start, specify a maximum heap size -Xmx property value that provides about 45% free memory, and a minimum heap size -Xms property value of approximately 50% of the maximum heap size.
Never specify a minimum heap size that is less than the maximum new area size (nursery size). Using Verbose Garbage Collection is one of most efficient ways to understand the memory utilization and the garbage collection behavior within the Java Virtual Machine (JVM). This feature adds detailed statements to the JVM error log file of the Application server about the amount of available and in-use memory. To set verbose garbage collection, see Tune the IBM virtual machine for Java.
Advantages of the 64-bit JVM
Start with Feature pack 1, WebSphere Commerce supports both the 32-bit and the 64-bit version of the WebSphere Application Server.
WebSphere Commerce performs well when running on both the 32-bit and 64-bit JVM. The 32-bit JVM maximum heap size (-Xmx) is limited to a maximum of 1.5 Gb. The 64-bit JVM maximum heap size can be arbitrarily large, although to take advantage of compressed references it should be smaller than 28 Gb. The 64-bit JVM provides a number of advantages over the 32-bit JVM:
- The 64-bit JVM gives you the ability to keep more cached data in the JVM heap. This leads to less reliance on the DynaCache disk offload feature and, as a consequence, less I/O traffic to disk.
- The tuning and deployment process for the 64-bit JVM can be simplified by not having to tune the disk offload performance. Significant operational savings can be realized for some customers.
- The ability to increase the maximum heap size beyond 1.5 Gb is beneficial when the store is experiencing heap contention issues due to large number of non-cacheable application objects.
WebSphere Commerce customers with highly tuned sites operating on platforms that have a very effective file system cache capability (for example AIX or Linux) may observe lower total throughput compared with 32-bit JVM-based site.