|
Problem |
After upgrading from V4.0.3 to V4.0.5, SIGSEGV errors are
received and Application Server crashes with the just in time (JIT)
compiler enabled . |
|
Solution |
After upgrading from V4.0.3 to V4.0.5, WebSphere®
Application Server crashes and SIGSEGV errors began to occur with JIT
enabled. When JIT was disabled, the Application Server did not crash;
however, performance degraded with JIT disabled.
Sun is aware of a problem with the JIT compiler and recommends an upgrade
to the Java™ SDK. In this case, the Java SDK was upgraded to 1.3.1_07.
The Application Server continued to crash with the updated SDK. The -Xms
and -Xmx settings were -Xms 512 and -Xmx 1024. After reviewing the
information listed below from the WebSphere Application Server V4.0.4 and
V4.0.5 Release Notes, the following additional changes to the
configuration were made:
- Set -Xms to 256 and -Xmx to 384, allowing garbage
collection to run more frequently for shorter periods of time.
- Changed the nativeheap size by entering the following into
the command line arguments:
-XX:maxPermSize=64m
After implementing the above changes along with the SDK upgrade, the
problem appears to be solved.
From the WebSphere Application Server Release Notes for V4.0.4 and V4.0.5:
Passing an appropriate maximum permanent heap size value to Java
virtual
machine to avoid an application server crash (Defect 131470.RN)
On the Solaris™ Operating Environment, an application server might crash
while under stress with a "java.lang.OutOfMemoryError", which is visible
in the stderr.log file of the application server.
To prevent this error, pass an appropriate maximum permanent heap size
value to the Java virtual machine (JVM). The default is too low. The
current suggested value is 64 MB, but it may need to set higher.
Perform the following steps to make this change using the administrative
console:
- Click application server.
- Click JVM Settings.
- Click Advanced JVM Settings.
- Enter -XX:MaxPermSize=64m (or higher if necessary) in Command line
arguments.
- Click OK.
- Click Apply.
You should also check the settings in use for the -Xms and -Xmx. If set
too high, garbage collection might not be running frequently enough and
take too long to complete. |
|
|
|
Historical Number |
PMR 29502
344
000 |
|
|
|
|
|