I don't think your seeing a real memory leak. What's happening is that the
logging mechanism in Tomcat doesn't actually write log messages to log files
when Logger.log() is called. Logger.log() adds a log entry to a queue and
returns immediately. A daemon thread then pulls the log entries off the
queue and writes to the log files.
If you server is running under a very high load and your doing logs of
logging, then the log queue may get very backed up and take up a lot of
memory. When the load comes down the log daemon will catch up and empty the
queue.
Log levels of INFORMATION and DEBUG create tons of log entries and really
aren't suitable for production or high load systems. I've run sustained
high load tests and monitored memory usage with JProbe and I haven't found
any real leaks in Tomcat.
> -----Original Message-----
> From: Rainer Jung [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 11, 2001 6:14 AM
> To: [EMAIL PROTECTED]
> Subject: Logging Memory Leak 3.2.2-beta2
>
>
> Hi!
>
> I use tomcat 3.2.2-beta2 on Solaris 2.6 with JDK 1.2.2_06 and
> apache 1.3.14
> on a Sun E420R with 4 CPUs and 4GB Memory.
>
> If I turn on verbosityLevel INFORMATION for JASPER_LOG in
> server.xml I can
> see a big memory leak. The leak does neither show up in version 3.2 nor
> does it appear when I use level WARNING:
>
> Also the leak only appears when I stress test tomcat with more than 32
> threads. Up to 30 Client Threads are handled without a leak, somewhere
> between the 32nd and 34th client thread the leak starts.
>
> After the leak appears I rapidly loose memory. If I give java as
> heap size
> 513MB and use verbose:gc I can see the heap growing in minutes
> and finally
> the Garbage collection locks up:
>
> GC[0] in 99 ms: (512Mb, 0% free) -> (512Mb, 0% free)
> GC[0] in 106 ms: (512Mb, 0% free) -> (512Mb, 0% free)
> GC[0] in 25 ms: (512Mb, 0% free) -> (512Mb, 0% free)
> GC[0] in 26 ms: (512Mb, 0% free) -> (512Mb, 0% free)
> GC[0] in 25 ms: (512Mb, 0% free) -> (512Mb, 0% free)
> GC[0] in 27 ms: (512Mb, 0% free) -> (512Mb, 0% free)
> GC[0] in 28 ms: (512Mb, 0% free) -> (512Mb, 0% free)
> GC[0] in 29 ms: (512Mb, 0% free) -> (512Mb, 0% free)
> GC[1] in 11622 ms: (512Mb, 0% free) -> (512Mb, 0% free)
> GC[0] in 129 ms: (512Mb, 0% free) -> (512Mb, 0% free)
> GC[0] in 99 ms: (512Mb, 0% free) -> (512Mb, 0% free)
> GC[0] in 24 ms: (512Mb, 0% free) -> (512Mb, 0% free)
> GC[0] in 25 ms: (512Mb, 0% free) -> (512Mb, 0% free)
> GC[0] in 25 ms: (512Mb, 0% free) -> (512Mb, 0% free)
> GC[0] in 22 ms: (512Mb, 0% free) -> (512Mb, 0% free)
> GC[1] in 12220 ms: (512Mb, 0% free) -> (512Mb, 0% free)
> GC[1] in 5479 ms: (512Mb, 0% free) -> (512Mb, 0% free)
> GC[1] in 9866 ms: (512Mb, 0% free) -> (512Mb, 0% free)
> GC[1] in 11792 ms: (512Mb, 0% free) -> (512Mb, 0% free)
> GC[1] in 11695 ms: (512Mb, 0% free) -> (512Mb, 0% free)
> GC[1] in 11869 ms: (512Mb, 0% free) -> (512Mb, 0% free)
> GC[1] in 11572 ms: (512Mb, 0% free) -> (512Mb, 0% free)
>
> Then essentially tomcat does no longer answer to requests.
>
> In my simple test-JSP I set the session attribute to false in the page
> directive:
>
> <%@ page session="false" %>
> <html>
> <body>
> X
> </body>
> </html>
>
>
> Any comments?
>
> Sincerely
>
> Rainer Jung
>
>
> kippdata informationstechnologie GmbH
> Bornheimer Straße 33a
> 53111 Bonn
>
> Tel.: 0228/98549-0
> Fax: 0228/98549-50
> email: [EMAIL PROTECTED]
