You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Guillaume Lahitette <GL...@abingdon.oilfield.slb.com> on 2005/03/03 10:50:56 UTC
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(ApplicationFilterChain.java:269)
at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:98)
at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:176)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:172)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.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(StandardContextValve.java:191)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.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(StandardHostValve.java:180)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:577)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.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(StandardEngineValve.java:174)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.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.processConnection(Http11Protocol.java:392)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:536)
root cause
java.lang.OutOfMemoryError
RE: OutOfMemory / JMeter / Profiler questions
Posted by Guillaume Lahitette <GL...@abingdon.oilfield.slb.com>.
Thanks Harry for your input. But we just can't do any upgrades to the
production environment at this point :( Hopefully soon.
Guillaume
> -----Original Message-----
> From: Harry Mantheakis [mailto:harry@mantheakis.freeserve.co.uk]
> Sent: 03 March 2005 10:45
> To: Tomcat Users List
> Subject: Re: OutOfMemory / JMeter / Profiler questions
>
>
> > 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
>
> I cannot help you with respect to your OOM problems, but I would recommend
> that you consider upgrading to JVM 1.4.2.
>
> You should also be able to migrate your app to TC 5.0.28 without too much
> grief. You should probably avoid TC 5.5.x for the meantime.
>
> JVM 1.4.2 and TC 5.0.28 play well together.
>
> Good luck in case!
>
> Harry Mantheakis
> London, UK
>
>
> ---------------------------------------------------------------------
> 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
Re: OutOfMemory / JMeter / Profiler questions
Posted by Harry Mantheakis <ha...@mantheakis.freeserve.co.uk>.
> 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
I cannot help you with respect to your OOM problems, but I would recommend
that you consider upgrading to JVM 1.4.2.
You should also be able to migrate your app to TC 5.0.28 without too much
grief. You should probably avoid TC 5.5.x for the meantime.
JVM 1.4.2 and TC 5.0.28 play well together.
Good luck in case!
Harry Mantheakis
London, UK
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org