Hi, I know Tomcat 3.2.3 in a banking production doing heavy work with huge uptimes - no memory leaks have been found (but: OS is Solaris).
The only time I thought there were memory leaks was also during stress test in two cases: 1) Having a lot of debug log output (but really a lot) 2) Using JSPs (or Servlets) creating a lot of web container sessions in tomcat Here point 2) perhaps needs further explanation: By default a JSP is embedded in a web container session. This session can be used by the developper to put data in the session, that the same user should be able to use later. Even if the developer does not use a session the pure existence of a session consumes memory. In a JSP you can set the session attribute of the page directive to false, if you don't use web container sessions. In case your stress test calls only small JSPs or servlets, which (implicitely) create sessions, you might end up creating 10s of sessions per second. Such an implicit session has a default timeout of 15 minutes, before it is freed. So it would be interesting how the memory bahaves with respect to time. A general debug strategy: simplify your setup, e.g. throw away all the backend logic in your JSPs/Servlets/helper classes. Reduce to a very simple JSP/Servlet to check, if you can really reproduce the leak in tomcat. Maybe it's in the code of some helper classes? Also if you have a possibility to try under a different platform (like Solaris) this might give an indication. You only need to put tomcat there, you can still leave IIS on Windows as the webserver. Rainer Jung At 17:31 19.12.01 , you wrote: >Make sure you don't have lots of logging turned on. Tomcat logs message >don't get written to the log files immediately. They go into a queue in >memory and a low priority thread later flushes message from this queue to >disk. If the server is really busy the log writer thread won't get to >execute and messages will back up in the in-memory queue. When the load >decreases the queue will be flushed and memory will be released. > >I've spent a fair amount of time running stress tests on Tomcat 3.2.x using >JProbe and I have not seen any memory leaks. > > >Marc Saegesser > > > -----Original Message----- > > From: Hawkins, Keith (Keith) [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, December 18, 2001 11:34 AM > > To: [EMAIL PROTECTED]; tomcat-user > > Subject: Ever increasing heap size with Tomcat 3.2.3 !!! > > > > > > > > Hello, > > > > Before my manager insists that we switch to JRun, can any of > > the Tomcat > > developers help with a problem of an ever increasing heap size of the > > Tomcat java.exe. ?? (We are running Tomcat 3.2.3 and > > JRE1.3.1. and the > > IIS redirector) > > > > We are running a load test using LoadRunner scripts on some JSP and > > servlets that are running under Tomcat. The load is not all > > that heavy > > but the heap size of the Tomcat java.exe process keeps growing and > > growing. We modified the java command line to start with -Xmx128m to > > allow 128 MB of heap but we still max out after a day or so. We even > > modified one of our servlets to create a thread that runs > > Runtime.gc() > > every 30 seconds. The LoadRunner scripts just keep logging > > in the same > > 5 people via our authentication servlet so you would think memory use > > would level out at some point. > > > > Nothing we do seems to keep the heap size from growing. > > > > Are there known issues with Tomcat and heap size?? > > > > Doing a web search revealed numerous posts with people having similar > > problems so I believe there is a problem. The standard > > response these > > people receive is to increase the heap size via -Xmx But that seems > > like a band-aid rather than a real solution. That just delays the > > inevitable. > > > > Any insight as to how to keep the Tomcat process from > > grabbing more and > > more memory would be appreciated. > > > > Thanks, > > Keith > > > > > > > > > > > > > > > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
