Low on total free memory

A JVM may run low on total free memory when there is a memory leak, the JVM heap was sized too small or there was a temporary abnormally high memory requirement (possibly for a very large order or wave).

If you encounter an OutOfMemory exception, we recommend you perform the following:

• Restart the JVM with a much larger heap.
• Monitor the amount of space used. For Oracle HotSpot JVMs, you need to look at the heap used after Full GCs. If you see this value steadily growing and never shrinking, you may likely have a memory leak. If the heap used increases by a large value (larger than your original heap setting) but eventually drops down to its original level, you may have encountered a large order or wave. You may want to investigate the nature of that order to see if the order was an anomaly or if it is going to be recurring. You can use the GC statistics to set you JVM heap sizes.

If you believe you have a memory leak, you can do the following:

• For IBM® JVMs, generate a heapdump and use the IBM Memory Dump Diagnostic tool to identify the memory leak. We have found this tool to be easy to use and easy to identify memory leaks. The IBM JVM automatically generates the heapdump when it runs into an OutOfMemory exception. You can also request a heapdump using a kill -3 by first setting the following environment variables:

  
     export IBM_HEAPDUMP=true 
     export IBM_HEAP_DUMP=true 
     export IBM_HEAPDUMPDIR=<directory to store the heap dumps>
  

• For Oracle HotSpot, try generating the hprof memory dump - the IBM Memory Dump Diagnostic tool is capable of analyzing hprof dumps. Otherwise, you may have to resort to using a tool like Quest JProbe Memory Debugger.