tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Bachrynowski" <Mike.Bachrynow...@thistle.co.uk>
Subject RE: Memory Mgmt Tomcat
Date Thu, 23 Jan 2003 15:02:10 GMT
We run high volume, load balanced and multiple web, servlet, application
and database servers on physically different machines. One of the
problem areas is persistence of sessions.  Even if the application knows
that a session is never going to be used again it hangs around and uses
memory until such time as Java garbage collection cuts in. This is good
in that the application does not have to worry about operational
issues.... but ....garbage collection is not too intelligent, it can
only do so much.   

In some of our Java servlets (the heavy processing ones) the application
explicitly kills the sessions when the application knows who the visitor
is and knows whether the session can be disgarded immediately.  The vast
majority of visits do not require sessions.  The most visits are from
robots from partners.  The next most visits are from robots from search
engines.  The next most visits are from humans who have not registered.
The next most visits are from humans who have registered but who do not
need state information.  Finally there are a relatively few visitors who
have registered and who require state information and hooray actually
buy services.  We had a 15 minute session time-out but before explicit
session killing at peak times session numbers built up, free memory fell
to danger levels slowing up the system and so the servers had to be
bounced.  After explicit session killing we have not seen the problem
again.

Static elements are being served by Apache so the only elements that
required to be served by the servlet servers are those that require
dynamic content (which are those that link to back-office applications).
Even those that require dynamic content only a few requests in the vast
numbers of requests require state information.  Applications can be
written using various techniques to further minimise the need for
persistent sessions...this is especially useful to maintain state even
if the visitor leaves the browser open on a particular page, goes to
lunch, retains and expects to pick up exactly where they left off (long
past the session timeout has expired).   

Opinions ?!?

Mike  


-----Original Message-----
From: Hari Venkatesan [mailto:hvenkatesan@pfgc.com] 
Sent: 23 January 2003 14:30
To: Tomcat Users List
Subject: RE: Memory Mgmt Tomcat


Shapira,

I don't think the question is ridiculous. There are a lot of people out
there who have implemented tomcat in production environment and we as
starters would like to know how they managed some of the delicate issues
like this. 

Off late there have been many  queries about memory management and the
reason behind this is because people get bombarded with "out of memory
error". 

Personally, I have been researching the same problem for almost a week
now, still without any right answers even after searching the archives.
Different JVM's do memory management in its own way and that is even
more confusing. 

You start tomcat with -verbose:gc, you can see GC kicks in even as it
starts. From what I learnt from java.sun.com, a full GC kicks in only
after it reaches its max heap. But you can see Full GC's in the verbose
output even before the JVM reaching its max heap. 

This makes you believe that something is wrong somewhere and that is
when people come out here to post their question to get some light from
experienced users of tomcat. 

By the way I have gone through the entire archive about this topic and
none of them give a final answer.

Hari

  
-----Original Message-----
From: Rommel Sharma [mailto:rommshar@cisco.com] 
Sent: Thursday, January 23, 2003 9:20 AM
To: Tomcat Users List
Subject: RE: Memory Mgmt Tomcat

Thanks! Thats the lead I was looking for...

-----Original Message-----
From: Shapira, Yoav [mailto:Yoav.Shapira@mpi.com]
Sent: Thursday, January 23, 2003 7:37 PM
To: Tomcat Users List
Subject: RE: Memory Mgmt Tomcat


Howdy,
The reason no one answered your original question is because it's kind
of ridiculous ;)  I don't mean that in an offensive way.  I do mean:

- Java has its own garbage collector.  Tomcat doesn't need to implement
its own.  There is much information on this topic on java.sun.com and
other general java forums.
- Many many many threads have gone on this list regarding garbage
collection and how to tune for it.  Search the list archives for more
details.

Yoav Shapira
Millennium ChemInformatics


>-----Original Message-----
>From: Rommel Sharma [mailto:rommshar@cisco.com]
>Sent: Thursday, January 23, 2003 9:11 AM
>To: Tomcat Users List
>Subject: Memory Mgmt Tomcat
>
>Hi!
>   I think the answer give to Nate should help, but just in case some
one
>knows how to do performance tuning of Tomcat when heavy objects are
being
>used, for effective 'memory management' then please put some light on
the
>topic.
>Thanks,
>Rommel.
>
>-----Original Message-----
>From: Shapira, Yoav [mailto:Yoav.Shapira@mpi.com]
>Sent: Thursday, January 23, 2003 7:30 PM
>To: Tomcat Users List
>Subject: RE: Resources for a Context
>
>
>Howdy,
>Can you please illustrate a possible use for this feature before you 
>start coding it?  A use case which can't be addressed by the servlet 
>spec, that is.  Right now, I doubt such a contribution would be
accepted
>into tomcat's core, so you may not want to waste time writing it at all
>;)
>
>Yoav Shapira
>Millennium ChemInformatics
>
>
>>-----Original Message-----
>>From: David Keyes [mailto:david.keyes@flashline.com]
>>Sent: Wednesday, January 22, 2003 5:10 PM
>>To: Tomcat Users List
>>Subject: RE: Resources for a Context
>>
>>I would be happy to make any modifications that would be required.
>I've
>>spent a bit of time looking around at the source already, but I'm not
>sure
>>what the best approach would be.  It would be nice if it could be done
>in a
>>"plugin" kind of way, but after looking around a bit, it seems that
the
>>concept of a single physical directory as a docbase is pretty
ingrained
>>(comments?).
>>
>>So far, I've looked at the following:
>>
>>1. Writing a new catalina Context implementation
>>2. Writing a new jndi DirContext implementation, that would be
>configurable
>>to take multiple directories
>>
>>Of those two, I think #2 makes the most sense, but I have doubts as to

>>whether it would solve the problem.  What I'm afraid of is that the
>changes
>>required are peppered throughout the Tomcat codebase.  Any pointers
>that
>>you could give me to get me started in the right direction initially
>would
>>be hugely appreciated.
>>
>>The only reason that I'm spending so much energy on this is that for
>very
>>large web applications that are not structured as a webapp, which I
>think
>>is rather common, it would be a HUGE aid in debugging to be able to
>pull
>>something like this off.  The code/compile/debug cycle gets a bit 
>>cumbersome when one is constantly redeploying large apps.  I think for

>>deployment the spec works just fine.
>>
>>Thanks again for your help, and all of your excellent work.
>>
>>Dave Keyes
>>
>>-----Original Message-----
>>From: Craig R. McClanahan [mailto:craigmcc@apache.org]
>>Sent: Wednesday, January 22, 2003 4:24 PM
>>To: Tomcat Users List
>>Subject: RE: Resources for a Context
>>
>>
>>
>>
>>On Wed, 22 Jan 2003, David Keyes wrote:
>>
>>> Date: Wed, 22 Jan 2003 15:53:22 -0500
>>> From: David Keyes <david.keyes@flashline.com>
>>> Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
>>> To: Tomcat Users List <tomcat-user@jakarta.apache.org>
>>> Subject: RE: Resources for a Context
>>>
>>> So what mechanism would you suggest for making MORE than one
>Resources
>>> directory available for a Context?
>>
>>* Modify Tomcat to support multiple resources directories
>>  (It's open source :-).  Note that you're violating the letter
>>  and spirit of the servlet spec's requirements on webapp
>>  organization, so it would be problematic accepting such a
>>  change back into Tomcat's core.
>>
>>* Use symbolic links (which doesn't help Windows users much).
>>
>>* Build deployment scripts that copy everything you need in the webapp
>>  together.
>>
>>Craig
>>
>>
>>--
>>To unsubscribe, e-mail:   <mailto:tomcat-user-
>>unsubscribe@jakarta.apache.org>
>>For additional commands, e-mail: <mailto:tomcat-user- 
>>help@jakarta.apache.org>
>>
>>
>>--
>>To unsubscribe, e-mail:   <mailto:tomcat-user-
>>unsubscribe@jakarta.apache.org>
>>For additional commands, e-mail: <mailto:tomcat-user- 
>>help@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail: 
><mailto:tomcat-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: 
><mailto:tomcat-user-help@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail:   <mailto:tomcat-user-
>unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:tomcat-user- 
>help@jakarta.apache.org>


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


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


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


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


Mime
View raw message