IBM BS029ML Self Help Guide - Page 158

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 Default value n/a Recommended value -Xnoclassgc GC Helper Threads n/a -XgcthreadsN 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 slow and consumes 144 IBM WebSphere Portal V6 Self Help Guide