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: [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] > >> > > >> > > >> > >> > >> > >> -- 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]
