Gencon garbage collection policy with IBM FileNet P8 Content Engine

Body

I was recently working with a 5.x Content Engine deployed into a 32-bit WebSphere 7.x/jdk 1.6 environment where the JVM was returning OutOfMemory errors during bulk document ingestion through a customer CE API application. The java heap was configured with an initial size of 512 mb and a maximum heap of 1228 mb with the default JDK 1.6 optthruput garbage collection policy. Verbose garbage collection was enabled and the resulting log file was analyzed. The used heap space when plotted over time during the document ingestion shows the used heap space gradually increasing.

The Content Engine, during document ingestion, will create a large amount of short lived objects. For this reason the performance tuning guide in the IBM FileNet P8 documentation suggests that to improve overall throughput to implement a generational garbage collection strategy.
The performance tuning guide also says the workloads that could benefit from generational garbage collection are applications that:

• Allocate many short lived objects
• Are transaction based where object in the transaction are deleted after the transaction is committed
• Tend to develop a fragmented heap

With a generational concurrent garbage collector, objects are allocated in the young generation (the nursery). When the young generation is full, the JVM stops all Java threads and moves the live objects in the young generation to the old generation (the tenured).
WebSphere® format: -Xgcpolicy:gcType, Example: -Xgcpolicy:gencon

Oracle JRockit format: -Xgc:gcType, Example: -Xgc:gencon

Java HotSpot: Generational garbage collection is the default setting.

So I wanted to try the gencon garbage collection policy in this environment to see if I would get better memory utilization over the default garbage collection strategy. I also increased the default nursery size to be about 25% - 50% of the heap size

For the generational garbage collection policy my JVM parameters were set as follows:

-Xgcpolicy:gencon

-Xms=768m

-Xmx=1228m

-Xmns=256m (setting nursery initial size)

-Xmnx=512m (setting nursery maximum size)

With the gencon garbage collection policy parameters in place, I repeated my bulk document ingestion with verbose garbage collection enabled. This time I did not receive any OutOfMemory errors. The used heap space when plotted over time during the document ingestion shows the used heap space increase and decrease in the normal peak and valleys you would expect from a gencon policy. The important thing to note was the median heap space was fairly constant.


So it appears, at least in this 32-bit environment, that a generational concurrent garbage collection policy manages the memory better than the default optthruput policy. For a 64-bit environment with a lot more addressable memory space, I would suggest trying JVM parameters similar to:

-Xgcpolicy:gencon

-Xms=2048m

-Xmx=4096m

-Xmns=512m (setting nursery initial size)

-Xmnx=1024m (setting nursery maximum size)