[Geoserver-users] Apache Tomcat crashing...

Swap space looks like this:
total used free shared buffers cached
Mem: 8306064 6183208 2122856 0 60492 5620972
-/+ buffers/cache: 501744 7804320
Swap: 4096532 656 4095876

Thanks for the link. The “Troubleshooting and Diagnostic Guide” seems to be full of information but it’s getting a little bit late for this hardcore java action (and a new episode of “Californication” will be aired in half an hour ;)).

I almost forgot: There was an older trunk version of GeoServer 1.7 (with the GeoSearch module) and GeoWebCache running in Tomcat.

regards
Stefan

-----Ursprüngliche Nachricht-----
Von: Lehtonen, Mika [mailto:mika@anonymised.com]
Gesendet am: Donnerstag, 14. August 2008 22:29
An: geoserver-users
Betreff: Re: [Geoserver-users] Apache Tomcat crashing…

Hi Stefan,

I found this:

The next improvement is visible when the system is almost out of swap
space and an allocation from the native heap fails in the VM. In that
case the VM aborts and you get a one-line error such as the following:

Exception java.lang.OutOfMemoryError: requested 16 bytes
for CHeapObj-new. Out of swap space?

This message has been known to confuse a lot of developers. At first
glance it might it might look like that the java heap is
full. Of course
if you increase the size of the heap with the -mx option it
might make
the problem worse as the larger java heap means there is less native
memory available.

from:
http://blogs.sun.com/alanb/entry/outofmemoryerror_looks_a_bit_better

I don’t know whether it will help but maybe you can give it a
try. Could
there really be problems with the swap space? You’d better check it.

  • mika -

Ziegler Stefan kirjoitti:

Hi
after running Apache Tomcat for a whole month without problems, it
crashes now too often (after approx. 2 days). The error I get:
“java.lang.OutOfMemoryError: requested 140 bytes for
CHeapObj-new. Out
of swap space?”

My JVM options:
export MALLOC_CHECK_=0
JAVA_OPTS=“-Djava.awt.headless=true”
JAVA_OPTS=“$JAVA_OPTS -server "
JAVA_OPTS=”$JAVA_OPTS -XX:SoftRefLRUPolicyMSPerMB=36000 "
JAVA_OPTS=“$JAVA_OPTS -Xms128m -Xmx768m "
JAVA_OPTS=”$JAVA_OPTS -XX:PermSize=128m "
JAVA_OPTS="$JAVA_OPTS -XX:MaxPermSize=256m "

Is there a way to find out which process makes Tomcat crashing? (I
have two other servlets running in Tomcat) And how to avoid
crashing
Tomcat this often? [GeoServer 1.6.4b, Apache Tomcat 5.5.25 on a Red
Hat Enterprise Linux ES release 4 (Nahant Update 6)]

regards
Stefan

Mit freundlichem Gruss
Stefan Ziegler
Leiter Aufsicht

Kanton Solothurn
Bau- und Justizdepartement
Amt für Geoinformation
Rötistrasse 4
4501 Solothurn
Telefon 032 627 75 96
Telefax 032 627 75 98
stefan.ziegler@anonymised.com
http://www.so.ch





This SF.Net email is sponsored by the Moblin Your Move
Developer’s challenge
Build the coolest Linux based applications with Moblin SDK
& win great prizes
Grand prize is a trip for two to an Open Source event
anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/




Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users



This SF.Net email is sponsored by the Moblin Your Move
Developer’s challenge
Build the coolest Linux based applications with Moblin SDK &
win great prizes
Grand prize is a trip for two to an Open Source event
anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/


Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Ziegler Stefan ha scritto:

Swap space looks like this:
total used free shared buffers cached
Mem: 8306064 6183208 2122856 0 60492 5620972
-/+ buffers/cache: 501744 7804320
Swap: 4096532 656 4095876

Thanks for the link. The "Troubleshooting and Diagnostic Guide" seems to be full of information but it's getting a little bit late for this hardcore java action (and a new episode of "Californication" will be aired in half an hour ;)).

Looking at the page Jukka linked I see this:

"In Mustang this condition will trigger the VM to invoke the fatal error handling mechanism. This means you should get a fatal error log as you would get with a normal (abnormal?) crash. The fatal error log is named hs_err_<pid>.log and contains useful information about the thread, process, and system at the time of the crash. In the case of native heap exhaustion then the heap memory and memory map information in the log can be useful. The exact format is version and platform specific and you will get more information in the J2SE Troubleshooting Guide."

Mumble, can we see the contents of that hs_err_<pid>.log file?
Cheers
Andrea