Using a higher acceptCount doesn't hurt much (needs maybe 1k memory for each queue place i think)
On earlier Java Versions there is a switch to turn on incremental Garbage Collection (off by default), -Xincgc (may decrease performance)
which is kind of similar to Concurrent GC i think, so worth a try if nothing else helps
At 20:08 11.07.2003 +0000, you wrote:
We are currently starting up with -Xmx256M. Java is currently using about 327MB and has been that way for hours. I haven't really seen any fluxuations at all, which leans me away from the garbage collection issue.
I created a hello.jsp, which is completely separate from our application. Same
results. It takes about 30 seconds to return.
In the hello.jsp, the results of the page return instantly to the browser, but
then it's as if tomcat just won't close the connection to the browser. The
page is there, fully rendered, but just sits there waiting for the server to
tell it it is done. Is there some way that the tomcat connections could be
failing to terminate properly?
Our current maxProcessors = 75 acceptCount = 10 (which is probably low but right now we have only a couple users on the system).
We're not using 1.4 so those options are out.
-- Dave
> Could be a Memory Leak/Garbage Collection issue (we had a similar problem
> with a memory intensive app),
> maybe your heap is too small and java is running many Full GC's.
> Start java with -verbose:gc and look in tomcat/logs/catalina.out for
> Garbage Collections.
> (set Environment Variables JAVA_OPTS or CATALINA_OPTS in bin/catalina.sh to
> do this in Tomcat)
>
> ================================
>
> Try using a bigger Heapsize (though if you've got a Memory Leak that will
> only delay your problem)
> or set initial Heapsize to same as maximum, for example 128MB:
> -Xmx128m -Xms128m
>
> ================================
>
> Modify the Connector you are using to access Tomcat (in
> tomcat/conf/server.xml) and
> try using more Tomcat Processors (maxProcessors=XX) or a bigger accept
> queue length (acceptCount=XX)
> (test value for acceptCount: at least > concurrent users x 3)
>
> ================================
>
> Try using another method of garbage collection,
> if you're using JDK 1.4.1 i'd try either
>
> ConcurrentGC with ParNewGC (ParNewGC on Multi-CPU machines):
> -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
>
> or ParallelGC with AdaptiveSizePolicy (saves you the work of Java Heap
> usage analyzing :-) :
> -XX:UseParallelGC -XX:+UseAdaptiveSizePolicy
>
> A good article on GC can be found here:
> http://wireless.java.sun.com/midp/articles/garbagecollection2/
>
> ================================
>
>
> At 18:04 11.07.2003 +0000, you wrote:
> >With Tomcat 4.1.x
> >
> >We've recently run into an issue where some of our pages either
> >a) take a really long time to come up (20+ seconds) or
> >b) come up, but never really finish loading (the status bar in IE shows
> >the the
> >response hasn't finished).
> >
> >These are very simple pages (for example, a login page) and our server
> >load is
> >minimal (maybe 10 concurrent users). Then, mysteriously, the problem will go
> >away by itself. It will also return.
> >
> >Given the information above, I'm not expecting any solutions, but I could use
> >some help steering me in the right direction with things to check. We're
> >hooking up monitoring on the systems (Linux) to examine memory and CPU
> >utilization during the slowdowns.
> >
> >Any things in particular we should be examining to try to find the problem?
> >Any idea why the pages would never fully return from the server?
> >
> >TIA
> >
> >-- Dave
> >
> >---------------------------------------------------------------------
> >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]
>
--------------------------------------------------------------------- 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]
