Alan, Thanks for your feedback. You got me curious here: Why does/would Tomcat reload sessions after startup? Aren't the sessions destroyed upon Tomcat shutdown?
Also, I could only find a $TOMCAT_HOME/work/Standalone/localhost/prti-rpt-engine.2.4.2.b17/SESSIONS.se r, which is NOT the context I have been load testing. Sessions should be serialized per context, shouldn't they? We do not store anything in the session (our test just calls a servlet which generate a PDF report) so I can't see why the sessions would be using so much memory. But I'll definitely keep your idea in mind for other tests. I should hopefully be able to run the same tests on our staging platform and see if we get similar behaviors. Thanks for your inputs. Please keep them coming! Cheers, Guillaume > -----Original Message----- > From: Flisch, Alan [mailto:[EMAIL PROTECTED] > Sent: 03 March 2005 12:17 > To: Tomcat Users List > Subject: RE: OutOfMemory / JMeter / Profiler questions > > > You probably have either very large or very many sessions which > Tomcat is attempting to reload on startup. Tomcat serialises > sessions into files called SESSIONS.ser (in the application > directories under the work dir) and then when it is restarted it > attempts to reload them all. I presume this behaviour can be > turned off. > > In terms of testing your app, you want to figure out whether you > have a memory leak issue with your app, or simply that your max > heap size is set too low for the load you are running. To check > for memory leaks, you could run jmeter reasonably (although not > too hard) excercising as much of your app as you can, > repetitively and for an extended period. If it eventually keels > over then you may need to investigate memory leaks with a profiler. > > Another possibility is that you may not be invalidating sessions > and they are just being left to expire naturally. This can use > up a lot of memory if you aren't careful and I supect is a quite > likely source of your problems. > > Cheers! > > > -----Original Message----- > From: Guillaume Lahitette [mailto:[EMAIL PROTECTED] > Sent: 03 March 2005 09:51 > To: [email protected] > Subject: OutOfMemory / JMeter / Profiler questions > > > Hello Tomcat'oids! > > We've started performance testing one of our REMOTE web apps > using JMeter. We're gathering benchmark data before doing further fine > tuning. > > Details: > Win2K > only have ssh + cygwin access to this remote server > JDK 1.4.1_03 > Tomcat 4.1.26, running as a service: > a.. Use security manager 1 > b.. Security policy file D:\Tomcat4\conf\catalina.policy > c.. Initial heap 256 > d.. Max heap 512 > e.. Stack size 256 > f.. JVM server > Issue: > We are getting OutOfMemory errors with very few threads simulated > (as low as 5). More problematic, we've seen the OOM just after a > Tomcat service restart! > From the stack trace below, you can see we get the OOM before any > of our code is executed :( > > Questions: > a.. Anyone has seen this behavior upon Tomcat start up? > b.. Anything particular to watch for in our JMeter test plan? > c.. Would a profiler help? Could it profile a remote Tomcat > installation? Any +/- feedback on Eclipse Profiler plug in > (http://eclipsecolorer.sourceforge.net/index_profiler.html)? > We'll work on gathering more data (e.g. periodic free / allocated > memory dumps). Untill then, thank you for sharing your > experiences, suggestions, code,...! > > Cheers, > Guillaume > > javax.servlet.ServletException: Servlet execution threw an exception > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(A > pplicationFilterChain.java:269) > at > org.apache.catalina.core.ApplicationFilterChain.access$000(Applica > tionFilterChain.java:98) > at > org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationF > ilterChain.java:176) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicati > onFilterChain.java:172) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapp > erValve.java:256) > at > org.apache.catalina.core.StandardPipeline$StandardPipelineValveCon > text.invokeNext(StandardPipeline.java:643) > at > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline. > java:480) > at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardConte > xtValve.java:191) > at > org.apache.catalina.core.StandardPipeline$StandardPipelineValveCon > text.invokeNext(StandardPipeline.java:643) > at > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline. > java:480) > at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) > at > org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2416) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValv > e.java:180) > at > org.apache.catalina.core.StandardPipeline$StandardPipelineValveCon > text.invokeNext(StandardPipeline.java:643) > at > org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispat > cherValve.java:171) > at > org.apache.catalina.core.StandardPipeline$StandardPipelineValveCon > text.invokeNext(StandardPipeline.java:641) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValv > e.java:172) > at > org.apache.catalina.core.StandardPipeline$StandardPipelineValveCon > text.invokeNext(StandardPipeline.java:641) > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:577) > at > org.apache.catalina.core.StandardPipeline$StandardPipelineValveCon > text.invokeNext(StandardPipeline.java:641) > at > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline. > java:480) > at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngine > Valve.java:174) > at > org.apache.catalina.core.StandardPipeline$StandardPipelineValveCon > text.invokeNext(StandardPipeline.java:643) > at > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline. > java:480) > at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) > at > org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:601) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.pr > ocessConnection(Http11Protocol.java:392) > at > org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565) > at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(Thre > adPool.java:619) > at java.lang.Thread.run(Thread.java:536) > > root cause > > java.lang.OutOfMemoryError > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
