so the total process memory will always be bigger than the maximum specified heap
(unless this isn't a bug or a misunderstanding of me of course :-)
Our Tomcat 4.1.24 on Redhat Linux with 1GB heapsize consumes about 1,25GB Memory at its maximum.
At 16:13 11.07.2003 -0400, you wrote:
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.
-- DaveCould 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]
