You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Travis De Silva <td...@bigpond.net.au> on 2004/09/17 08:52:21 UTC

Windows 2003 Java VM memory leak due to C# garbage collection algorithm

Hi,

Wish someone could provide us insight to the following problem that we encounter. We have been trying for nearly two months now researching the web including this forum and trying out various suggestions but have been unsuccessful so far.

What we would like to know is that if there is a memory leak in our application, it should grow within the java heap and eventually give an out of memory error and crash the JVM. This is what I have known from the first day I got into Java and have always thought this to be correct. (until now)

We are running a Tomcat/5.0.27, 3 node cluster (on the same Windows Server 2003) and use the AJP13 connector to redirect requests from IIS 6.0 (running on IIS 5.0 isolation mode) (tried with Tomcat 5.0.19 as well. The JVM :1.5.0-rc-b63 tried with 1.4 as well) Using the recommended Oracle JDBC thin drivers for this version of the JVM, we connect to Oracle 9i which also runs on the same server.

The issue we are having is that the VM size for each of the Java.exe processes grows way beyond the max heap settings. (we understand that it will not be equal due to the JVM loading overhead)

For example, the heap settings is set to 512MB per tomcat/JVM instance but on Windows, it keeps growing to about 1.5 GB. This happens to each of the nodes and it goes into virtual memory and then eventually crashes and we have to restart the Tomcat cluster. 

Now I know with regard to Java application memory leaks, you got to check your programs. But what I want to know is that if there is a memory leak from our programs, it should eventually take the full java heap and then crash with an out of memory error. But that does not happen. In fact by monitoring the GC output, the heap seem to be working fine with each GC run increasing the free memory. In fact when we monitor the tomcat status page as well, we do see the java heap memory behaving correct. Also as I said, there are no out of memory errors in the log as well.

What I want to know is even if our program has a memory leak, it should crash the JVM right? It should not keep increasing the memory allocated from the Windows Server 2003 O/S. 

Could this be a issue with the Windows server 2003 garbage collection as I read it is written using C#? anyone has any idea if this is the problem? 

Any help would be very much appreciated.

Thanks

Travis

AW: Windows 2003 Java VM memory leak due to C# garbage collection algorithm

Posted by SH Solutions <sh...@gmx.net>.
Hi

> What I want to know is even if our program has a memory leak, it should
crash the JVM right?

No, your program (better your webapp) should get OutOfMemoryExceptions and
should continue running. Mostly, it will not do sensful things any more, but
it should NEVER crash the JVM.

> It should not keep increasing the memory allocated from the Windows Server
2003 O/S.

Right. It should go about 64 MB over your max heap setting (which is approx.
the jvm overhead), but not 1 GB above. There is something wrong. Are you
sure you specified both MIN AND MAX heap values? Can you show your OPTS? How
are you starting tomcat - as service or as application?

> Could this be a issue with the Windows server 2003 garbage collection as I
read it is written using C#? anyone has any idea if this is the problem? 

No.
Windows 2003 server has nothing to do with applications garbage collection.
Java JVM have their own garbage collector, you can even choose one from
command line - what you could try.
Windows 2003 itself has no garbage collection at all. Windows 2003 provides
.net by default, which itself works semtantically like a VM and which itself
DOES HAVE a garbage collector. That one IS used for C#, but I doubt it is
written in C#.
And even if it would be written in C#, that should not be the problem, since
it is used in really huge applications and has not shown to be a big source
of leaks so far.

Regards,
  Steffen


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org