It might also be that Tomcat needs more memory than the JVM will allocate. We had that problem.
With the Sun JVM, the options "-Xss128k -Xmx128m" increased the stack and max heap size and there no longer was a problem.
Try to set CATALINA_OPTS in bin/startup.sh:
CATALINA_OPTS="$CATALINA_OPTS -server -Xss128k -Xmx128m"
Otherwise, try to get MRTG to graph your Tomcat's memory usage, like it's done in the attached PNG.
Best regards,
-- DAvid
--On Monday, March 07, 2005 4:49 PM +0000 James Sys <[EMAIL PROTECTED]> wrote:
I've seen similar problems in a non-Tomcat Java application.
The root cause was a memory leak. Although Java has good garbage collection, it relies on object references being released.
This is generally fine, but some buggy applications can add references to large object to the application and forget to release them. This causes memory to be consumed, the app so slow and eventually the app or server to lock.
With Tomcat, I can imagine this happening with objects continually being added to, say, an ArrayList in the Application context and not being released.
I believe there are various tools around to check object allocation and release. So if you see objects of a certain type have a gradually increasing number, you may well have a memory leak.
Hope this helps.
Regards,
James. =====
Hi All,
For the past couple of months we have been facing a peculiar problem on our production environment. And we have been unable to resolve this issue so far.
We have an application hosted on Tomcat 4.1.30 and using JDK1.4.2_06. We also have an Apache WS - (think it is v2.0.2). Everyday approx after every 24 hours of uptime the website slows down and hangs... On checking the tomcat logs, we see an OutOfMemoryException.
Restarting Tomcat was one way to momentarily fix the issue and have the site up - but due to Apache forked processes we are not able to restart Tomcat too. Even if could our Tomcat takes about 30-40 mins to load/startup due to some user data loading on startup.
So that leaves the only option of killing certain threads/processes and then starting Tomcat. which works fine - only we have been doing this every night for the past more than a month.
We also got a thread dump just to check what is going on.. and I have pasted that info herewith. Sun has suggested that we install all patches to the JDK.
I just wanted to find out if anyone had faced a similar issue and if there was something they did that fixed the issue. Was Tomcat the culprit?? We will go ahead and install the patches very soon - but wanted to be ready in case that didnt fix the issue - did anyone experience an improvement once the patches were installed?? ***************************** Here is the Exception Trace:
An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0xFF380CBC Function=memcpy+0x7E0 Library=/usr/platform/sun4u/lib/libc_psr.so.1
Current Java thread: at COM.ibm.db2.jdbc.app.DB2PreparedStatement.SQLBindChar(Native Method) at COM.ibm.db2.jdbc.app.DB2PreparedStatement.execute2(DB2PreparedStatement.java
:1020) - locked <0x9ec56ef8> (a COM.ibm.db2.jdbc.app.DB2Connection) at
COM.ibm.db2.jdbc.app.DB2PreparedStatement.executeUpdate(DB2PreparedStatement .java:807) at com.waveset.repository.RelationalDataStore$Item.setPersistentObject(Relation alDataStore.java:999) at com.waveset.repository.AbstractDataStore.setItems(AbstractDataStore.java:492 6) at com.waveset.repository.AbstractDataStore.set(AbstractDataStore.java:1804) at com.waveset.repository.AbstractDataStore.checkin(AbstractDataStore.java:1758 ) at com.waveset.repository.AbstractDataStore.set(AbstractDataStore.java:1804) at com.waveset.repository.AbstractDataStore.checkin(AbstractDataStore.java:1758 ) at com.waveset.repository.AbstractDataStore.checkin(AbstractDataStore.java:1401 ) at com.waveset.repository.ServerRepository.checkin(ServerRepository.java:2276) at com.waveset.session.InternalSession.checkinObject(InternalSession.java:581) at com.waveset.task.Scheduler.storeExecutingTask(Scheduler.java:1515) at com.waveset.task.Scheduler.executeReadyTask(Scheduler.java:2918) at com.waveset.task.Scheduler.processReadyTasks(Scheduler.java:2837) at com.waveset.task.Scheduler.processTasks(Scheduler.java:1031) at com.waveset.task.Scheduler.run(Scheduler.java:866)
Dynamic libraries: 0x10000 /www4/j2sdk1_4_2_06/java/usr/j2se/bin/java 0xff360000 /usr/lib/libthread.so.1 0xff39a000 /usr/lib/libdl.so.1 0xff280000 /usr/lib/libc.so.1 0xff380000 /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1 0xfec00000 /www4/j2sdk1_4_2_06/java/usr/j2se/jre/lib/sparc/client/libjvm.so 0xff240000 /usr/lib/libCrun.so.1 0xff210000 /usr/lib/libsocket.so.1 0xff100000 /usr/lib/libnsl.so.1 0xff1e0000 /usr/lib/libm.so.1 0xff1c0000 /usr/lib/libsched.so.1 0xff270000 /usr/lib/libw.so.1 0xff0d0000 /usr/lib/libmp.so.2 0xff0b0000 /usr/lib/librt.so.1 0xff090000 /usr/lib/libaio.so.1 0xff060000 /usr/lib/libmd5.so.1 0xff040000 /usr/platform/SUNW,Ultra-80/lib/libmd5_psr.so.1 0xfebd0000 /www4/j2sdk1_4_2_06/java/usr/j2se/jre/lib/sparc/native_threads/libhpi.so 0xfeb80000 /www4/j2sdk1_4_2_06/java/usr/j2se/jre/lib/sparc/libverify.so 0xfeb40000 /www4/j2sdk1_4_2_06/java/usr/j2se/jre/lib/sparc/libjava.so 0xfeb20000 /www4/j2sdk1_4_2_06/java/usr/j2se/jre/lib/sparc/libzip.so 0x737d0000 /www4/j2sdk1_4_2_06/java/usr/j2se/jre/lib/sparc/libnet.so 0x74910000 /opt/IBMdb2/V7.1/java12/libdb2jdbc.so 0x71c00000 /opt/IBMdb2/V7.1/lib/libdb2.so.1 0x73ea0000 /usr/lib/libresolv.so.2
Heap at VM Abort: Heap def new generation total 226112K, used 67456K [0x75800000, 0x83b80000, 0x83b80000) eden space 219264K, 27% used [0x75800000, 0x79331618, 0x82e20000) from space 6848K, 100% used [0x82e20000, 0x834d0000, 0x834d0000) to space 6848K, 0% used [0x834d0000, 0x834d0000, 0x83b80000) tenured generation total 1864192K, used 1152200K [0x83b80000, 0xf5800000, 0xf5800000) the space 1864192K, 61% used [0x83b80000, 0xca0b2380, 0xca0b2400, 0xf5800000) compacting perm gen total 21248K, used 20838K [0xf5800000, 0xf6cc0000, 0xf9800000) the space 21248K, 98% used [0xf5800000, 0xf6c59a40, 0xf6c59c00, 0xf6cc0000)
Local Time = Mon Feb 7 23:44:49 2005 Elapsed Time = 42200 # # The exception above was detected in native code outside the VM # # Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode) # # An error report file has been saved as hs_err_pid13341.log.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- David Tonhofer
M-PLIFY S.A. Resp. Informatique 47, av. de la Libert� L-1931 Luxembourg Tel: +352 261846-52 Fax: +352 261846-46 Mob: +352 021-139031
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
