tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hua Hou <...@handango.com>
Subject RE: -Xincgc, -Xms600, -Xmx600
Date Mon, 02 Jun 2003 17:12:00 GMT
One correction: 
  Package the StringBuffer.class into a jar file and put the jar file under
<Tomcat-Home>\common\endorsed directory. Tomcat will not pick up class file
from that directory, only jar files.



-----Original Message-----
From: Hua Hou 
Sent: Monday, June 02, 2003 11:10 AM
To: 'Tomcat Users List'
Subject: RE: -Xincgc, -Xms600, -Xmx600

I was experiencing similar problem with Tomcat 4.1.24 + JDK1.4.1_02. When
turning on "-verbose:gc", I found that when the memory usage reaches the
-Xmx setting, Full GC will kick in and try to claim the unused memory back.
However, because of the JDK1.4.1_02 memory leak bug, the Full GC keeps
running for 200 cycles (continuously) (which hangs the whole system for
quite some time) and eventually I got "Out-of-Memory" error.

My fix to this problem was to replace the setLength() method in StringBuffer
(JDK1.4.1_02) with the setLength() method in JDK1.3.1_07 version and place
the customized StringBuffer.class file under <Tomcat-Home>\common\endorsed
directory and now the problem goes away. 

Of course, there are too many factors to your problems and these are just my
2 cents.

Hua

-----Original Message-----
From: Shapira, Yoav [mailto:Yoav.Shapira@mpi.com] 
Sent: Monday, June 02, 2003 10:16 AM
To: Tomcat Users List
Subject: RE: -Xincgc, -Xms600, -Xmx600


Howdy,

>I question whether this is a memory issue. Even if you use 600MB, why
does
>tomcat run at 100% cpu forever??? Shouldn't the gc finish???

GC may finish and immediately restart if memory is still full.  That
would keep CPU usage pegged.

>I have had this same problem with Tomcat for quite some time too. It
seems
>to be an issue with Tomcat installed as a service ... or possibly some
>issue with the jk connector. 

Both of those seem to be reasonable theories.

>I am using jdk1.3.1_07. I know that people upgraded to jdk1.4 and the
>problem persists ... so it's probably not a JVM issue.

I don't think that's a possible conclusion without significant further
investigation.  There are simply too many variables, too many difference
between JDK 1.3.x and 1.4.x, and "people" vs your specific situation.

Can you see if it's actually GC that's using the CPU?  If not, what is?
One way to find out is to ctrl-break your tomcat when it's using 100%
CPU.  You will get output showing what exactly every thread in the VM
was doing.

Yoav Shapira



This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, proprietary
and/or privileged.  This e-mail is intended only for the individual(s) to
whom it is addressed, and may not be saved, copied, printed, disclosed or
used by anyone else.  If you are not the(an) intended recipient, please
immediately delete this e-mail from your computer system and notify the
sender.  Thank you.


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

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

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


Mime
View raw message