tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Turner <tomcat-u...@johnturner.com>
Subject Re: Need help with performance issue - Tomcat 4.1.X
Date Fri, 11 Jul 2003 20:38:03 GMT

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, <tomcat-question@comcast.net> 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, <tomcat-question@comcast.net> 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, <tomcat-question@comcast.net>

>> 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- 
>> unsubscribe@jakarta.apache.org
>> >> >> >For additional commands, e-mail: tomcat-user- 
>> help@jakarta.apache.org
>> >> >>
>> >> >>
>> >> >> -------------------------------------------------------------------

>>
>>
>> --
>> >> >> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>> >> >> For additional commands, e-mail: tomcat-user- 
>> help@jakarta.apache.org
>> >> >>
>> >> >
>> >> >
>> >> > --------------------------------------------------------------------

>>
>>
>> -
>> >> > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>> >> > For additional commands, e-mail: tomcat-user- 
>> help@jakarta.apache.org
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> -- Using M2, Opera's revolutionary e-mail client: >> 
>> http://www.opera.com/m2/
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>> >> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>> > For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>> >
>> >
>>
>>
>>
>> -- Using M2, Opera's revolutionary e-mail client: 
>> http://www.opera.com/m2/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message