tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johannes Fiala" <tom...@fwd.at>
Subject Some thoughts on memory consumption and gc
Date Sun, 01 Jun 2003 14:58:59 GMT
Hi there,

I've made some tests with the gc and the -Xms and -Xmx settings. 
Suppose I have a list generated from a database with a size of 10.000 
records with an average of 200 bytes each. This gives 2 MB data volume.

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

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

*) 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? 

*) 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. 
Anyway, right at the time one passes control from the Servlet (Controller) 
which invoked the model and filled it to the view (jsp), we'll have a lot 
of memory allocated per request. 

*) Has anybody practical experience with Garbage collector tuning? 
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?
(I already tested with Borland Optimizeit and no SQL or Oracle objects 
lurk around in memory longer than needed).

I've previously programmed with many other programming languages, and 
never "leaked" memory or had any memory issues (ok not to mention C, but 
there you have full memory control and responsibility). With Java memory 
issues are always hard to track but occur frequently in load tests. Has 
anybody tips available how to keep track of memory consumption easily.

Any input is highly appreciated,
Johannes
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message