Java Runtime Execution require reboot of pSeries server regularly?

Dear all experts,
Recently the daily batch run process (run using Java Runtime Execution)suddenly run slow. Our apps vendor came in and check and request to reboot the server. After rebooting of the server, the batch run back to normal.
May I know is periodically rebooting of pSeries server is a requirement?
As I know pSeries server is built for less downtime. I would like to know whether any other way to refresh Java Runtime Execution instead of reboot of server.
Thanks.

What a mystery. The JAVA executable should not care about the history of the server. Maybe there was little swap left, or something such, that forced the JVM to gc more often. The java executable and your app should not be more sensitive than any other executable or application. What sort of resources does the JAVA app use (network, RDBMS, NFS files, local files)?

yep you do not give us anything we could work with - like for example the OS you are using - the applications running on your box and so on. There are certain issues with 32bit applications that might cause your issues - and with some runtime settings these issues are relatively easy to fix. But to help you we would obviously need to know a little bit more :slight_smile:

regards
zxmaus

Well, it is an AIX forum, so we should hope . . . . Maybe some disk space is being filled up to the point that a journalized volume puts a slower media into play? I recall we had an issue with excess churn in an Oracle device on raid5 SAN slowing the whole shebang down. Of course, IBM . . . steel ball . . . rubber mallet. :smiley:

Thanks for all the replies.
The server is running AIX 5300-07-08.
A power 5+ server with 6 duo-core CPUs, memory of 21GB with paging space set to 21GB as well. The storage set to RAID10 (as recommended by vendor that RAID 5 is not good on performance)
VM setting has been set to Oracle preferred setting as
maxclient% and maxperm% = 90
minperm% = 3
lru_file_repage = 0
lru_poll_interval = 10.

Java running is as below
Java5_64.sdk 5.0.0.175

Hope these enough info for solving the mystery.

Again, thanks a lot for the replies.

Any reason to stay away from later JAVA? If you try 6.23 and it goes away . . . .

Are there any residual processes accumulating as time passes, like zombies or stopped?

I will check with DBA and vendor on whether we can upgrade to the latest version. Meanwhile, any support that the slow problem is due to the version? I need to in some way prove it to vendor and DBA.
Thanks.

Perfect knowledge is a sort of religious goal, and mere mortals must sometimes just try for a fix. So, try things. Nothing will be fixed until you try things. Nothing can be proven to be a fix until you try it.

Which JAVA RDBMS is this?

Can you test one process on a different JAVA using client PATHing?

I believe IBM's startegy is that you pay them extra and they try things, not to authorize you to try things. :smiley:

5300-07 not stable, upgrading.

Let us know how that affects things! Good Luck!