Responding to the issue though the chain is closed so that someone gets benefited from it in future.
This is a small write up I drafted from some of the documents of SAG webMethods:
JVMs use Garbage Collection (GC) as a mechanism to reclaim unused memory. The garbage collection
process is managed entirely by the JVM.
Garbage collection typically interrupts execution of all threads except the garbage collection helper
threads. Therefore, frequent garbage collection can impact the performance of the Integration Server
significantly. One simple way to lengthen the time between garbage collections is to increase the Java
heap size. Note that this will also potentially lengthen the duration of each garbage collection pause,
since the JVM will have to reclaim more memory.
To learn more about the garbage collection where your Integration Server is running, start the JVM with
the “-verbose:gc” switch. This switch tells the JVM to log information relating to garbage collection.
The logs contain information relating to frequency of garbage collection, length of time spent for each
garbage collection, amount of memory reclaimed during each garbage collection, and so forth. For more
information about the “-verbose:gc” switch, consult JVM documentation for the specific JVM in use.
Most JVM vendors provide a number of options that you can use to fine-tune the garbage collection
process. Discussing different garbage collection options offered by different JVM vendors for different
versions is beyond the scope of this document.
Eliminate unnecessary audit logging.
Make sure the Integration Server’s “watt.server.auditLog” parameter is set to “perSvc” and
not to “brief” or “verbose”. Example:
Heap Settings and Memory
The amount of memory available to the Integration Server is determined by the size of the maximum
heap you allocate to the JVM. The heap is the memory area in which the Java Virtual Machine (JVM)
creates and stores objects. Because the heap is the only portion of memory that the Integration Server
uses for data storage, the size of the heap (not the amount of memory installed on the machine)
ultimately determines how many documents the Integration Server can actually process at one time.
Heaps that are too small
A heap that is too small will produce out-of-memory errors. A small heap may also cause sluggish
performance due to frequent pauses for garbage collection (reclamation of memory that is no
longer in use).
Heaps that are too large
Performance will also degrade significantly if the machine does not have enough physical memory
to expand the heap to its configured maximum size and must then page portions of the heap to
virtual storage (disk).
To determine how much of the heap your Integration Server uses, start the server and load only those
packages that you expect to load under normal operating conditions. Immediately after the server loads,
use the Integration Server Administrator to examine the Available Memory value on the “Settings >
Resources” page. The “Available Memory” value will indicate how much of the heap is available for
processing your documents. You can monitor this value as your solution executes to track its memory
From ©2011 Software AG webMethods Advanced Troubleshooting Guide Page 18
By default, the Integration Server is configured to allocate an initial heap size of 128MB, and configured
to expand to a maximum heap size of 256MB. You can change the size of the heap memory in the
Integration Server startup file:
° Windows: server.bat ( now setenv.bat, 8.x onwards)
° Unix/Linux: server.sh
To change the size of the heap, set the following Java parameters in the start-up file for the Integration
A common performance-tuning measure is to make the initial heap size (JAVA_MIN_MEM) equal to the
maximum heap size (JAVA_MAX_MEM). Doing this prevents heap expansion and contraction, and can
produce performance gains in some situations.
Some operating systems limit the amount of memory that a single process can use. For example,
Windows 32-bit machine does not allow a process to use more than 2 GB of memory. So, even if you equipped a
Windows 32-bit machine with 4 GB of memory, the Integration Server will never use more than 2 GB of it.
Some early versions of the JVM also restrict the maximum size of the heap. When tuning memory to
improve performance, you need to be aware of any limitations that your existing operating system and/or
JVM may impose. You may find that you need to switch operating systems and/or JVMs to achieve the
heap size you need.
Also, before you provide the Max Perm Gen memory, run jvisualvm.exe which will enable you to know how much of Perm Gen memory you actually need, use a good buffer and then assign the values. It helps to substantially bring down the Integration server Performance.