Table of Contents
Advertisement
Setting the JVM heap size to or greater than 1 GB on AIX necessitates reducing maxdata (the
boundary between the permissible data area and the shared memory region in the AIX
memory model). However, this shift effectively steals segments from the data area. One
limitation that a smaller data area might impose would be in the ability to create native
threads, as each thread has a native stack that is in turn allocated from the native heap.
Note that in addition, when using a Java heap greater than 1 GB with the 1.4.x IBM JVM on
AIX, the Java heap will be allocated with mmap() and not malloc().
Setting the JVM starting minimum heap size equal to the JVM maximum heap size, without
first performing an analysis, gives little overall benefit in terms of long term performance gain.
Therefore, we recommend that you refrain from setting the JVM starting minimum heap size
equal to the JVM maximum and instead allow the heap to expand until it reaches a
steady-state. This will ultimately allow you to determine at what value the heap usage
stabilizes. Furthermore, setting the JVM starting minimum heap size equal to the JVM
maximum heap size when using a large heap can lead to memory (native heap)
fragmentation.
Important: The JVM heap is preallocated (in terms of native memory) at the maximum
heap size, so setting a large Java heap size effectively reduces the amount of physical
memory available to the system. Under no circumstances should the JVM heap page out
to disk. Calculate the free memory available after all other applications and the OS
requirements have been taken into account.
Additional IBM JVM attributes
In addition to modifying the JVM heap sizes, the following additional attributes can be
evaluated.
To view or modify the IBM JVM settings from the WebSphere Application Server
Administrative Console, select Servers → Application Servers → WebSphere_Portal →
Server Infrastructure → Java and Process Management → Process Definition → Java
Virtual Machine. The default and recommended values are shown in Table 5-2.
Table 5-2 Additional IBM JVM settings
Parameter
Prevent GC of class loaded data
GC Helper Threads
The -Xnoclassgc setting prevents garbage collection (GC) from reclaiming class loaded data;
only de-referenced user objects are reclaimed, and can offer a significant performance
improvement. However, the parameter should be fully evaluated for suitability due to the
nature of class loaded data. Be aware that dynamically compiled JSPs constitute class
loaded data.
With the addition of the -XgcthreadsN parameter, the default number of garbage collection
(GC) helper threads that are used during the mark phase, can be explicitly overridden.
Platforms with N processors will have N-1 helper threads available by default, which work
alongside the master thread to complete the mark phase of GC. N is an integer.
If mark stack overflows are observed while performing a verbose garbage collection trace,
then additional helper threads may alleviate the problem. Mark Stack Overflows are indicative
of deep or wide structures in the Java heap. Processing such structures leads to an overflow
of the mark stack, which in turn triggers a sequential heap scan; this is
144
IBM WebSphere Portal V6 Self Help Guide
Default value
n/a
n/a
Recommended value
-Xnoclassgc
-XgcthreadsN
slow
and consumes
Advertisement
Table of Contents
Troubleshooting
