Tune heap to accommodate more large objects

Identify Java stack that creates large objects | Performance Monitoring Infrastructure (PMI)

Tune heap to accommodate more large objects

+
Search Tips | Advanced Search

Overview

It is not always possible to avoid creating large objects.
IBM Sovereign 1.4.2 SDK SR1 and later supports the configuration of large object area (LOA) to reserve the Java heap for allocating large objects (>=64 KB).
Specify option -Xloratio. to reserve parts of the JVM heap for large objects. This part of the Java heap will never be used for small object allocation (<64 KB).
For example, to reserve 20% of the active Java heap, (not 20% of -Xmx, but 20% of the current size of the Java heap) to the allocation of large objects (>= 64 KB) only, use the option...
-Xloratio0.2

When an allocation request for an object not less than 64 KB arrives, the process first tries to allocate from the remaining 80% of the heap. If it is unable to allocate, it then tries to allocate in the exclusively reserved area for large objects.
-Xmx should be changed to make sure that you do not reduce the size of the small object area, by using the following formula:
[New Xmx] = [Current Xmx] / (1 - [loratio])

For example, we need at least 1462 MB for -Xmx to use -Xloratio0.3 with current -Xmx1024 MB:
1024 MB / (1 - 0.3) = 1462 MB

IBM Recommendation

Generally, thorough analysis of the verbosegc trace is needed to decide whether to configure the -Xloratio. WebSphere Commerce recommends that you start with...
-Xloratio0.1

If this is not enough, increase LOA with the following information as a general guideline. If you see fragmentation of the Java heap because of large objects (>= 64 KB) and there is a significant number of allocation failures due to these objects, then you can enable Xloratio with 0.2 or 0.3.
From the verbosegc, if you see that 0.2 or 0.3 is being used up and the Java heap is still fragmented because of large objects, then consider increasing Xloratio to 0.4 or 0.5.

How to read LOA utilization

Consider this sample GC trace:
<AF[2163]: Allocation Failure. need 17112 bytes, 18162 ms since last AF>
<AF[2163]: managing allocation failure, action=1 (259024/472958976) (86602816/118239744)>
<GC(2163): mark stack overflow[1849]>
<GC(2163): GC cycle started Fri Mar 14 00:11:06 2008
<GC(2163): heap layout: (180404344/472958976) (108889384/118239744) /0>
<GC(2163): freed 202431888 bytes, 48% free (289293728/591198720), in 342 ms>
<GC(2163): mark: 310 ms, sweep: 32 ms, compact: 0 ms>
<GC(2163): refs: soft 0 (age >= 32), weak 12, final 968, phantom 3>
<AF[2163]: completed in 344 ms>
LOA utilization is displayed in the second bracket on the lines of managing allocation failure and heap layout:.
In the line of....
<AF[2163]: managing allocation failure, action=1 (259024/472958976) (86602816/118239744)>

The second bracket displays (86602816/118239744), which indicates 86602816 bytes (86MB) out of 118239744 bytes (118MB) is free in the Large Object Area. Subtract 86MB from 118MB, we get 32MB in LOA being utilized.
After the GC cleanup, in the line of:

<GC(2163): heap layout: (180404344/472958976) (108889384/118239744)

...we see 108889384 bytes (108MB) out of 118239744 bytes (118MB) is free in LOA, which means only 10MB of LOA is used.
In this example, the user's LOA is set to 0.2, which is more than enough. There is no need to increase LOA. The user may even want to lower it back to 0.1 and continue monitoring.

How to configure LOA

Add the -Xloratio to Generic JVM Arguments in the administrative console:
On WebSphere Application Server V6.0 select...
Servers | Application Servers | server_name | Java and Process Management | Process definition | Java Virtual Machine | Generic JVM Arguments