If your JVM runs out of heap space, you should get an OutOfMemoryException thrown. Same, if you don't have sufficient stack space, you should get a StackOverFlowException.
I had a problem with a JSP that sometimes would take as much as 15 minutes to serve. It creates a table of sometimes a few hundred rows, each containing a selection box and a submit button. I ended up rewriting it as a Java class that first builds the outtput message in a StringBuffer using append() and then writes the buffer to the output stream in a single operation. That increased performance by more than one order of magnitude. I suspect that there is an issue with the way Jasper created servlets use the out.write()/out.print() methods. Lars -----Original Message----- From: John Turner [mailto:[EMAIL PROTECTED] Sent: Friday, July 11, 2003 1:38 PM To: Tomcat Users List Subject: Re: Need help with performance issue - Tomcat 4.1.X Like I said, I'm no guru. Sounds like you need to bust out a profiler. John On Fri, 11 Jul 2003 20:34:40 +0000, <[EMAIL PROTECTED]> wrote: > But again, the mx is only setting the heap size, not the whole JVM. The > thread stack is controlled with an entirely different parameter for > example. > > I found this with a quick search: > > "The -Xmx setting controls the maximum size of the Java heap. > > However, the Java heap represents only part of the memory taken up by a > running Java application. There is space required for code, data space > used > by the JIT, plus any memory malloced by native code drivers associated > with > the application running in the JVM. So the overall memory picture for > Java > applications turns out to be more complex than just the -Xmx value." > > -- Dave >> >> I have no idea, but based on past experience, if you are using more RAM >> than you've allocated, then you have a swap situation. If the max >> setting wasn't an actual max, and you could blow past it whenever you >> needed it, why on earth would you need it in the first place? >> >> John >> >> On Fri, 11 Jul 2003 20:24:48 +0000, <[EMAIL PROTECTED]> wrote: >> >> > I definitely don't know enough about how the memory settings in java >> to > be of much use on this part. I do not know if we've tried 512. We >> > probably should. >> > >> > As for the 327, is that actually unreasonable? The mx setting >> specfies > the maximum heap size. Can the thread stack (specified using >> -Xss, which > we're not using) be taking up the remaining 75MB? We have >> about 40 > threads started right now. >> > >> > Like I said, I don't know enough about java's memory allocation, but I >> > didn't think that the -Xmx set the maximum allowable total memory for >> the > JVM. Am I mistaken? >> > >> > Even if memory were a problem, which it may be, would that account for >> a > 20 second delay between serving a page and closing the connection? >> > Remember that we currently have no load and only a couple users on the >> > system. >> > >> > -- Dave >> >> >> >> I'm certainly no guru, but if you are setting a max of 256 and then >> your >> app is soaking up 327 with no load whatsoever, I'd say you have >> a >> problem. Have you tried a max of 512? >> >> >> >> John >> >> >> >> On Fri, 11 Jul 2003 20:08:10 +0000, <[EMAIL PROTECTED]> >> 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: tomcat-user- >> [EMAIL PROTECTED] >> >> >> >For additional commands, e-mail: tomcat-user- >> [EMAIL PROTECTED] >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------- >> >> >> -- >> >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> >> For additional commands, e-mail: tomcat-user- >> [EMAIL PROTECTED] >> >> >> >> >> > >> >> > >> >> > -------------------------------------------------------------------- >> >> >> - >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> > For additional commands, e-mail: tomcat-user- >> [EMAIL PROTECTED] >> >> > >> >> > >> >> >> >> >> >> >> >> -- Using M2, Opera's revolutionary e-mail client: >> >> http://www.opera.com/m2/ >> >> >> >> --------------------------------------------------------------------- >> >> 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] >> > >> > >> >> >> >> -- Using M2, Opera's revolutionary e-mail client: >> http://www.opera.com/m2/ >> >> --------------------------------------------------------------------- >> 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] > > -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ --------------------------------------------------------------------- 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]
