hello,all.
We are using IS 6.1 on HP-UNIX. And the Max Java Memory size is 1.5G. Everything works well right after the IS rebooting. But after a period, say 1 month, the memory usage can be 90 percent and the server reacts really slowly. When we came into this situation, the only thing we can do is reboot. But i think that is not the right way.
Is there something more we can do to solve this problem? Any comments are highly appreciated.
BTW There are no error message on server log
Thanks.

Shenjie

I recommend restarting the integration servers every week (or at least every other week). Have you enabled verbose garbage collection? What do the logs say for the garbage collection information? How often is it doing full collections?

I typically put this entry in the server.cnf file (via extended settings is also fine) …

watt.server.cache.gcMins=30

You can also tune the garbage collection so it logs to a different log file (other than nohup.out).

matt

Java tuning is a very important and not quick process. You can typically improve your application response time/performance significantly by doing this.

However, no amount of Java tuning will handle poor coding practices or a Java application that has a minor leak. Over time, both of these conditions will take up a lot of your available memory. The safest course is to have a periodic reboot of the JVM. If your app has a maintenance window, shoot for that timeframe. If it’s a 24x7 app, then you have more than one server to guarantee availability. Find a slow period and reboot one server, then the other server.

Good luck.

Thanks Matt.
We havn’t done the garbage collection. So there is no log file for this info.
And could you please describe in detail how to do it both in the server.sh (for hp unix) and server.cnf (for windows) ?
And how to tune the garbage collection to log for a different file?
BTW, nohup.out is the default log info? Since we’ve no idea about this file could you talk about this file more? We ofen use the serveryyyymmdd.log file in the logs folder.

  Thanks again!

Shenjie

You may have to work with TS on this.

We had a problem after implementing Service Pack 4 on 6.01 (The problem was actually in Service Pack 3, but we went from Service Pack 2 to Service Pack 4) anyway there was a memory leak in a provious fix to SP2 (Fix 84 I believe) that caused a rapid memory leak. I investigating this leak, we noticed a minor leak that we had similar to yours, but we are on a windows platform so our machines a patched and booted every month so we never noticed and issue.

BTW - it took forever to convince webMethods the problem was theirs, they came back with the “No one else reports this” so it could not be an issue.

Shenjie,
For Garbage collection - you need to add the following flag to the JAVA2_MEMSET argument
“-verbose:gc”

It is the same for both Windows and Unix.
This will give you an idea as to what was the memory when your IS crashed.

The verbose output in case of Unix will be sent to the nohup.out file.
In case of HP, you should be starting the server using nohup, correct?
If not, how are you starting the server?

For logging the verbose output in Windows, you need to start the server from the command line. The verbose output will be sent to the command window.

You need to determine what is running on the server that is taking up memory. Generally the Garbage collection should run and reclaim the memory.

This may be a JVM issue as well.

thanks sjain.
But i havn’t found JAVA2_MEMSET in our server.sh. Do you mean I just add this in the .sh file like : JAVA2_MEMSET -verbose:gc ? And where should I add it?

The only argument which is similar to this is :JAVA_MEMSET=“-ms${JAVA_MIN_MEM} -mx${JAVA_MAX_MEM}” . but i don’t think there is anything to do this is argument.

And We do start the IS using nohup.

shenjie

What’s more.
To start the IS, besides nohup, we also wrote a .sh file to start :
/webmethod/wm61/IntegrationServer/bin/./server.sh -debug 6 &

This way, where would be the verbose logging info?

Thanks!

shenjie

Shenjie,
I think you should work with webMethods Technical Services as they will be able to better identify the issue.