Tuning your Java Virtual Machine (JVM) settings

You might need to tune your machine's JVM settings relative to the default values set by WebSphere Commerce to avoid experiencing memory allocation errors. The symptoms for these errors can vary from intermittent performance problems to the periodic failure and restart of the JVM which does not generate a core dump or error. Complete the tasks in the following sections.

Changing your JVM arguments

The JVM arguments are set to Xk22000 -Xp64k,16k by default at installation time. This should be sufficient for most applications. If you need to modify these settings from the defaults, update them as follows:

  1. Open the WebSphere Application Server Administration Console.
  2. Select Apserver > Apname > Process definitions > Java virtual machine
  3. In the Generic JVM arguments field, enter: -Xk22000 -Xp64k,16k
  4. Apply the changes.

For further information on using the Xk and -Xp arguments for your environment, refer to section on "Avoiding Fragmentation in the Developer Kit and Runtime Environment, Java 2 Technology Edition Diagnostics Guide for version 1.4.2.

Setting the initial and maximum heap sizes

You should start up your application with the minimum heap size that it needs. Then, when the application starts up, the Garbage Collector will run often and efficiently because the heap is small. When you have established the maximum heap size that you need, you might want to set the minimum heap size to the same value; for example, -Xms 512M -Xms512M. Using the same values is not usually a good idea because it delays the start of garbage collection until the heap is full. The first time that the Garbage Collector runs becomes a very expensive operation. Also, the heap is most likely to be very fragmented when a need to do a heap compaction occurs. Again, this is a very expensive operation.

Preventing heap fragmentation

Note that the following recommendations might not avoid fragmentation in all cases:

Garbage collection tracing

If you have not enabled garbage collection tracing (verbosegc),the JVM can fail and restart periodically without any visible symptoms other than slow performance. If you have enabled verbosegc, you can find the following errors can be found in the native_stderr.log file:<AF[2082]: Allocation Failure. need 255768 bytes, 7 ms since last AF> <AF[2082]: managing allocation failure, action=2 (62667808/536803840)> <GC(2104): mark stack overflow[1902]> <GC(2104): GC cycle started Fri Nov 19 21:48:04 2004 <GC(2104): freed 6116120 bytes, 12% free (68783928/536803840), in 4117 ms> <GC(2104): mark: 1719 ms, sweep: 105 ms, compact: 2293 ms> <GC(2104): refs: soft 0 (age >= 32), weak 0, final 1, phantom 0> <GC(2104): moved 2514995 objects, 299673064 bytes, reason=1, used 15808 more bytes> <AF[2082]: managing allocation failure, action=3 (68783928/536803840)> <AF[2082]: managing allocation failure, action=4 (68783928/536803840)> <AF[2082]: managing allocation failure, action=6 (68783928/536803840)> <AF[2082]: totally out of heap space> <AF[2082]: completed in 4129 ms> <AF[2083]: Allocation Failure. need 32784 bytes, 1817 ms since last AF> <AF[2083]: managing allocation failure, action=2 (28528/536803840)> <GC(2105): mark stack overflow[1903]> <GC(2105): GC cycle started Fri Nov 19 21:48:07 2004 <GC(2105): freed 67886448 bytes, 12% free (67914976/536803840), in 1702 ms> <GC(2105): mark: 1601 ms, sweep: 101 ms, compact: 0 ms> <GC(2105): refs: soft 0 (age >= 32), weak 0, final 120, phantom 0> <AF[2083]: completed in 1724 ms>

Feedback