JVM-1.3.0.01
HP-UX B.11.11
running on a UNIX box with 1.34gb VM,
server.sh set for:
JAVA_MIN_MEM=1024M
JAVA_MAX_MEM=1792M
JAVA_MEMSET=“-Xms${JAVA_MIN_MEM} -Xmx${JAVA_MAX_MEM}”
users are mapping flat files to IDOCs going into SAP. flat file is only 1.7MB yet server crashes (with core dump) when trying to process. getting “OutOfMemory” error even with 3.0gb physical mem on the box. webMethods I.S. is the only app on the box.
any ideas? this one seems to be stumping the WM tech support.
thanks
w
What does the server statistics screen say?
Look to see if the used memory is really displayed as JAVA_MAX_MEM, if not then the jvm setting isn’t working.
If it is, then lets figure out what is using the RAM.
How many concurrent users? See peak total sessions on Server > Statistics page.
Do you have verbose audit logging on for any service? If so, it doubles the memory use per user because the pipeline has to be deep clones and sent to the async audit logging service.
Can one user process one file at a time? If so, how much memory is used? Look at the Server > Service Usage screen to get a feel for the services that are executed and how often.
Do you have anything HP specific in this application? i.e. calling out to native libraries.
Has webMethods support been able to reproduce the problem? If not and nothing jumps out of your answers to these questions, it may be worth sending your package in to support for a recreate.
Was there ever any ‘resolution’ to this issue?
In the service that you wrote, do you have any loops? Rob Eamon had another thread that covers loops in total.
Here’s something that should work that I have used. WM support suggested bumping up the garbage collection in the server.cfg file.
There should be a setting as follows:
watt.server.cache.gc=60
I suggest changing to read:
watt.server.cache.gc=10
This sets garbage collection to every ten minutes. However, this service sends a prompt to the JVM to clean up, but doesn’t necessarily activate garbage collection. (we determined this using a rational purify monitoring OS level activity and JVM level activity.)
If that fails, then create a java service and add this line:
System.gc();
and then run it as a service. It totally cleans out all of the dead threads and unused objects. But, if you are processing something on a light machine (i.e., no power, no memory) it will hamper performance.
Also, I’m not sure which JVM you are running. They all act a little different. I’ve had the best luck with SUN since you run green threads natively.