IBM Forms Server Memory Tuning

How do you go about tuning your IBM Forms Server’s memory usage?  First, we need to understand how memory is allocated on the Forms server. There are two allocations that I pay particular attention to:

  1. The JVM’s heap memory
  2. Native memory in use by Form instances

If you were to look at a java.exe process for the Forms Server on Windows, this is what you might see.

Translator Process

If you’re not sure which Java process is the TranslatorServer, look at the SystemOut.log. The first line will say something like

WebSphere Platform [ND cf021312.01] running with process name sametimeNode01Cell\formsNode01\TranslatorServer and process id 8648

The “process id <number>” statement is important. You can see that 8648 is the PID of the java.exe process in my screenshot.

So I have a Forms Server with 565MB of memory. What makes up this 565MB?  Roughly speaking, it’s:

  • The JVM heap. This includes allocations made by not only Forms but also any other enterprise applications running – like your custom application that launches the form.
  • Stack allocations to run the application server code. In my opinion, the “other stuff” that is out of our control.
  • Native memory used by Forms.

The “native memory” one confused me when I was first told about it.  After all, isn’t all memory in the Java process backed by native memory? Here’s where it gets separated – and I’m over simplifying. When you open a Form, two memory allocations are made. There’s an object added to the heap and an object in native memory. The result is that the heap’s memory amount may only increase slightly but the java.exe process increases much more.

You can see that in two ways. First, monitor the Java heap. You can do this with the help of this post. Next, take a look at the Webform Server Console, which should be installed by default. For example,

Forms Native Memory

So of the 11 Forms in-process currently, the native memory amounts to 203MB.  But my Java heap is currently 255MB.  That’s 458MB in total, which isn’t exact but pretty close to the 565MB process memory.

What do you do with this information? Well it first shows you are really tuning two areas when it comes to memory – the Java heap and Forms cache (i.e. native memory). When native memory is exhausted, bad things happen – swapping or crashing. When the heap runs out, Java throws an OutOfMemoryException and fails the current task – like your Form fails to render.

Notice that 12 forms were loaded since the server started, but 11 are in the cache. This is because I submitted the 12th form. The other 11 were forms opened and the browser was closed. This was a notable observation because it means that forms can consume memory even though they are no longer in use. The server will reclaim inactive forms (I’m told) after 24 hours.

My suggestion is that to really tune the Forms Server, you need to observe both heap and native usage over time. It’s very difficult to answer the question, “If I have 200 forms, how much memory is required?” Each form’s memory will vary by the number of elements, operations, and data. So instead of working from the bottom up, work from the top down – a model based on actual usage patterns with proactive monitoring over time.