tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Will Hartung" <wi...@msoft.com>
Subject Re: Memory Mgmt Tomcat
Date Fri, 24 Jan 2003 19:18:03 GMT
Several replies...

> From: "Mike Bachrynowski" <Mike.Bachrynowski@thistle.co.uk>
> Sent: Thursday, January 23, 2003 7:02 AM
> Subject: RE: Memory Mgmt Tomcat


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

To me, this is one of the most major issues of Java Servlet engines in
general. When you have a Session with a long lifetime (15-30 minutes), you
are pretty much guaranteed that the Session object and its dependents are
going to thrown into the Old space on any reasonably active server.

This can be considered a Bad Thing as generational collectors tend to make
it "cheap" to GC the younger generations of objects, where a vast majority
of objects are created and thrown away. The older the objects get, the more
entrenched they become and, potentially, the harder (more expensive) they
are to GC.

The logic behind this is that many systems will have several essentially
static objects that are simply never going to go away during the life of the
program (say, for example, the java.lang.String class). As a generational
collector works through its heap of objects, it finds objects in the first
generation that never seem to Go Away and get freed. Eventually, the
collector will basicly tire of constant;y seeing this object and move into a
older generation, which gets swept less often than the younger generations.

A simplistic view is that you have, say, 3 pools of memory. As the first
pool fills up you go through it and discard the freed objects. After several
interations, you find that there are a bunch of objects that are always
there. Rather than constantly scanning those objects, you throw them into
another pool. When THAT pool fills up, you do the same thing, and so on.

The idea is to make the routine sweep of real garbage, (i.e. simple work
objects) as quick as possible.

Now, the problem with Sessions is that they have an extended lifetime. By
their very nature, Sessions are pretty much implicitly garbage, as they only
represent the lifespan of the users actual interaction with the application.
That means that sooner or later, the user will Go Away, and the Session will
have served its pupose and can be collected.

The problem of course is that there really isn't a way to enforce having a
user "log off" of an application. Most simply drift away never to return,
putting the application on hold until the Session times out, typically in
15-30 minutes for many apps. During that idle time, these Sessions are
buried into these older generation for objects. 30 minutes is a long time to
the Garbage Collector. After 30 minutes, it is easy to see how the JVM can
make the assumption that SessionID 12345 is as important to the application
as java.lang.String, and promote it to the same level in the heap.

So, while the young generation is designed to be quickly and rapidly flushed
through, the old generation can be more time consuming to process, mostly
because of its size and the number of objects.

If you have objects that are "too old" for the younger generation, but not
really "old enough" for the older generation, you end up with sort of a GC
thrashing scenario where you are filling the older generation faster than
necessary and causing more expensive GCs to happen.

Some of this can be tuned away with the GC parameters on the JVMs but that's
as much art as it is science.

The other problem regarding Sessions is also the simple fact that even with
a well tuned GC, they're still going to live with your application for at
least the amount of time that the Session times out.

What this means is that should your site get a sudden surge in traffic, your
site will have to "live" with that traffic potentially long after the
traffic has left. Like that big cloud of black smoke that a bus leaves as is
accelerates away from the bus stop. The bus is gone, but the stink lingers.

Mike has done some good work in identfying those requests which simply don't
need the Sessions. In our application, were pretty much doomed once the user
logs in (which they have to do to do anything). So, even the most casual
quick glance in our system can cause horrible repercussions within the
memory, unless they thoughfully hit the Log Out Button, but even that gets
real ugly because of how web apps work.

Long term, though, it's simply a matter that you should strive to keep your
sessions small. I don't know if Tomcat can persist the Sessions to disk and
deactive them before they time out (like after 5 minutes) in order to free
up some long term memory. No doubt, this can be done directly in code,
but...it's a tricky thing.

I know, this is a meaningless post with no real concrete help, but just some
observations.

Anyway, to move on...

> From: Hari Venkatesan [mailto:hvenkatesan@pfgc.com]
> Sent: 23 January 2003 14:30
> Subject: RE: Memory Mgmt Tomcat

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

Despite what was mentioned previosly, there are assorted reasons why folks
are getting the Out Of Memory exception.

A very common one is simply that the stock Sun JVM javac leaks memory, so if
you're compiling a bunch of JSPs, you WILL run out of memory and there isn't
much you can do about it (though there might be a way to fork the javac, I
haven't looked in to that).

Another issue that came up recently was that essentially once a Servlet is
loaded into Tomcat, Tomcat never Let's Go. This is normally not a problem.
Most Servlets are actually pretty small. However, since JSPs create
Servlets, if you have a lot of JSPs in your system, and they tend to have a
lot of content, then you will end up filling your heap with RAM copies of
your JSPs.

If you use JSPs like others use HTML or SHTML files, this too will cause you
to run out of memory.

But, simply put, Out Of Memory is not a GC problem, it's a resource problem
due to the application directly or side effects of the Tomcat implementation
(as mentioned above).

GC problems are when your JVM goes out to lunch for 2 minutes doing a Full
GC on a heap that's been half swapped to disk. Tuning of the GC is designed
to mitigate the surprises and impact of the collector upon your programs
execution.

Of course, the REAL problem with all of this is that the answer to anyones
question regarding this topic is "It Depends", because everyones situation
is different and a whole host of environmental aspects, system design,
coding practices, etc impact memory and there's no One Answer. Now, most of
those issues are almost impossible to cogently communicate over something as
low bandwidth as a mailing list.

It's funny how hard it is to communicate the important facts and details of
a problem, but how easy it is to communicate frustration and aggravation. If
only it were the other way around.

Regards,

Will Hartung
(willh@msoft.com)




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