Heap memory and garbage collection

The JVM runtime environment uses a large memory pool called the heap for object allocation. The JVM automatically invokes garbage collections in order to clean up the heap of unreferenced or dead objects. In contrast, memory management in legacy programming languages like C++ was left to the programmer.

JVM is the foundation or engine on which Sterling Selling and Fulfillment Foundation and the WebLogic or WebSphere® application server runs. If the JVM heap settings are not set correctly, the garbage collection overhead can make the system appear unresponsive. In the worst case, your transactions or the JVM could abort due to OutOfMemory exceptions. For more information, see OutOfMemory exceptions.

The optimal JVM heap settings depends on many factors such as the type of processing. For example, a JVM dedicated to servicing short lived transactions has different demands than one that services a few but very large transactions.

Heap settings

The default heap settings are appropriate for small applications. By default, the heap on AIX® starts at 4MB and can grow to 64MB. You must adjust the heap settings for your environment.

Fortunately, the IBM® JVM was designed to work with most scenarios with little tuning. From past experiences, we generally only set the initial and maximum heap size. The IBM JVM also provides good statistics to help monitor and tune the JVMs. See Mattias Persson, Holly Cummins, Java™ technology, IBM Style, Part 2, Garbage collection with the Extensible Verbose Toolkit, IBM for an excellent article on monitoring the JVM performance.

Starting recommendations

We recommend you configure the IBM JVMs with the following starting recommendations and test the JVMs under representative workloads and traffic volumes prior to going live in production.

As a starting point, you should configure the JVMs running the Sterling Selling and Fulfillment Foundation agents and application servers with a 384MB, 1024MB, or larger heap respectively. The following are two sample configurations to start the Sterling Selling and Fulfillment Foundation Schedule agent and a WebLogic application server:


   export PSALLOC=EARLY          # AIX Only
   export NODISCLAIM=TRUE        # AIX Only
   
   java -Xms384m -Xmx384m \
   -verbose:gc \
   com.yantra.integration.adapter.IntegrationAdapter 
   
   java -Xms1024m -Xmx1024m \
   -verbose:gc \ 
   weblogic.Server
Note: Before JDK 1.6, the gcInterval parameter was required to prevent excessive GC.

The -Xms and -Xmx set the initial and maximum heap size. When setting these values, keep the following guidelines in mind:

  • Set the initial (-Xms) and maximum (-Xmx) heap size the same - This eliminates the need of the JVM to decide when to expand or shrink the heap. This could also prevent the situation where there is not enough swap space when the JVM needs to expand the overall heap.
  • By default, Sterling Selling and Fulfillment Foundation caches reference data for performance. Depending on your data setup, you may have to increase the heap size or reduce the numbers of cached records. See Performance feature - reference data caching for more information on the caching feature.
  • You must ensure that the node has enough physical memory so that portions of the heap are not paged out.
  • You must ensure there is enough swap space to back the virtual address space requirement for all concurrently running JVMs or, if you are on AIX, ensure the JVMs are started with PSALLOC=EARLY and NODISCLAIM=TRUE. For more information, see Page space allocation policy.

Garbage collection statistics

We recommend that you continuously collect garbage collection statistics for all JVMs especially in production. The collection overhead is minor compared to the benefit. With the statistics, you can tell if:

  • A JVM has or is about to run into a memory leak.
  • The garbage collection is efficient.
  • Your JVM heap settings are optimal.
    
       
    

To enable GC statistics, set the -verbose:gc option. The JDK 1.5 Diagnostic Guide (IBM Developer Kit and Runtime Environment, Java Technology Edition, Diagnostic Guide, Version 5.0, SC34-6650) provides very good guidance on how to interpret the garbage collection statistics.