tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Filip Hanik" <>
Subject RE: Memory leak- yeah I know
Date Thu, 15 Jan 2004 01:22:04 GMT
RE: Memory leak- yeah I knowhi Michael, thanks for your info. I will look
into that as well and set those settings
The thing I am investigating right now is if the fact that we are
registering a lot of things with JMX causes some references to never be

more info to follow.
  -----Original Message-----
  From: Michael Yates []
  Sent: Wednesday, January 14, 2004 4:43 PM
  To: Tomcat Developers List
  Subject: RE: Memory leak- yeah I know

  I spent some time a while back trying to get some reproducibility into
memory use in Tomcat (4.1.24)
  I found that even sitting idle tomcats memory use would increase.

  Here is my original mail to the tomcat-dev mailing list
  <<4.1.24 secure connector throws a LOT of garbage>>

  After I did some more investigations and figured out a fix the following
bug was raised

  To reduce the amount of garbage thrown by tomcat I would recommend two
things, doing these might help you track down other memory issues.

  1 - Use -Xmx<someValue>m -Xms<someValue>m.
  The above sizes the heap to whatever value you put in there (note the
value is megabytes). I found (at least on the Solaris JVM) that sizing the
heap and making the min and max heap sizes the same not only sped up start
up but also made the garbage collector behave much better.

  2- Set the serverSoTimeout value to 0 in the connector configuration in
your server configuration file. This will prevent the sever socket timing
out. Which DOES throw garbage, and if it is a secure connector you are using
it throws SO much garbage that the garbage collector can not keep up too

  Using just number tip 1 above (as the fix to the bug above wasn't in
Tomcat 4.1.x before we needed to go into production. We managed to run at
something like 100 TPS for 48 hours with no falling over and no net increase
in memory usage.

  If you need any more information on the above let me know.

  Michael Yates
  Software Engineer, Location Center
  Nortel Networks Wollongong, Australia.

  -----Original Message-----
  From: Filip Hanik []
  Sent: Thursday, 15 January 2004 11:09 AM
  To: Tomcat Developers List
  Subject: RE: Memory leak- yeah I know

  Remy, absolutely no intentions of being sarcastic :), if there isn't a
leak, that is great, if there is, will fix it.

  I'm trying to figure it out, I didn't ask anyone else to spend time on it,
or even read my email. but if anyone is doing work on this lets work on it

  just got jprobe up and running, once I have ran a few tests, I will
experiment with the garbage collection, the memory is slowly growing, its
been running for an hour.


  -----Original Message-----
  From: Remy Maucherat []
  Sent: Wednesday, January 14, 2004 3:08 PM
  To: Tomcat Developers List
  Subject: Re: Memory leak- yeah I know

  Filip Hanik wrote:

  > Ok, I know that these emails are usually dismissed with the words:
  > "Gets us some proof from a profiler", and I will...gimme some time, in
  > the meanwhile, if anyone else wants to play with it.
  > well the story is that during heavy load tests of the session
  replication my
  > system my VMs always run out of memory.
  > What am I doing different than others, well, during my load tests I am
  > not using keep alive connections to achieve true round robin. I'm
  doing this by
  > setting method.setHttp11(false) in the Http client.
  > Running the test (attached, instructions below) I am hitting
  > http://localhost:8080/index.jsp (home page) and watching the
  memory grow and
  > grow and grow.
  > I am using a profiler and having somewhat of a hard time reading
  the output.
  > I am gonna download a trial of jprobe, see how that works out for
  > me... I will be back with results from that.
  > in the meantime, for those who want to see their memory grow here are
  > the instructions
  > My env:
  > Machine: PIII 1.6Ghz, 512MB Ram
  > OS: Redhat 8
  > VM: Sun JDK 1.4.2_02 (build 1.4.2_02-b03)
  > Instructions:
  > download the attached client.jar
  > execute:
  > java -cp testclient.jar;commons-httpclient.jar;commons-logging.jar
  > org.apache.catalina.cluster.test.client.MemTestClient http
  > :// 100 100000 1000 false (exchange ; for
  > : on
  > unix)
  > Watching the memory grow using Top, although it shouldn't increase at
  > all.

  There's ab for that kind of stuff, you know ... No need to waste your time
writing some new stuff. Your tone is a bit sarcastic, I think. I'm eagerly
awaiting your "proofs" ;-)


  To unsubscribe, e-mail:
  For additional commands, e-mail:

  To unsubscribe, e-mail:
  For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message