tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <Yoav.Shap...@mpi.com>
Subject RE: Some thoughts on memory consumption and gc
Date Mon, 02 Jun 2003 13:29:59 GMT

Howdy,

>*) If you have 128 MB heap and 64 MB stack memory assigned, against
which
>will the memory consumption count?

Mostly the heap.  The stack space is used for method overhead and other
miscellaneous information.

>*) According to my experiements Runtime.availableMemory will give me
the
>heap size. How can I determine the stack size (without using a
profiler)

Not possible in a standard way that I know of using the Sun JVMs.  You 
are expected to know what it is from your java command arguments.

>*) Given the 2 MB memory consumption per request, does this effectively
>mean that the server will be able to support a maximum of 64 concurrent
>requests?

Likely less than 64 concurrent requests, as there are other things on
the
heap as well.  In general, retrieving whole large data sets into memory
on
demand will reduce the number of concurrent users you can serve and
indicates a pool design from a scalability perspective.

>*) To my mind it seems that the MVC approach doesn't come in very handy
>here, the only solution would be to split the list into smaller parts.

You can make a scrollable design using an MVC approach.

>*) Has anybody practical experience with Garbage collector tuning?

If you search the archives, you will see many many posts on this
topic.  My guess is that among the members of the list there are many
man-years of experience in this area.  Furthermore, there are many
articles on gabrage collection, including tuning and troubleshooting,
on java.sun.com and other sites.

>Currently it seems my gc may come in too late and this will result in
>OutofMemoryExceptions (of course I close all database connections
properly
>and always use finally to free Connections). Does anybody have ideas
how
>to trace such issues?

Use -verbose:gc and a profiler.  Don't look just for SQL objects.  
Look to see where you data is held, and for how long.

>(I already tested with Borland Optimizeit and no SQL or Oracle objects
>lurk around in memory longer than needed).

Data could be held elsewhere, preventing its collection.
Using something like OptimizeIt will show you where.  

>there you have full memory control and responsibility). With Java
memory
>issues are always hard to track but occur frequently in load tests. Has

I disagree.  I find issue easier to track in Java than almost any
language
I've used, partially due to the availability of excellent tools.

Yoav Shapira



This e-mail, including any attachments, is a confidential business communication, and may
contain information that is confidential, proprietary and/or privileged.  This e-mail is intended
only for the individual(s) to whom it is addressed, and may not be saved, copied, printed,
disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately
delete this e-mail from your computer system and notify the sender.  Thank you.


---------------------------------------------------------------------
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