Another followup. If we try to access the root context of the server, which is not available, the same thing happens. I get back a 500 error immediately, but then the page doesn't finish "loading" (i.e. get all the response back from the server) for another 20 seconds or so.
This seems like a connection problem rather than a memory problem. Thoughts? -- Dave > 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]
