tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: java.lang.OutOfMemoryError: Java heap space
Date Mon, 05 Oct 2009 19:53:23 GMT
Joe Hansen wrote:
> Thank you for the reply, Andre.
> I now understand how setting KeepAlive to On would improve the
> performance of a website (The Apache manual says that a 50% increase
> in throughput could be expected). So I changed the KeepAlive to On and
> restarted the server.

Now wait.
You should probably then lower your setting for KeepAliveTimeout (to 3 
e.g.), otherwise you may make the problem much worse.
Read conscienciously the relevant Apache doc page :

The point with KeepAlive is :
- the browser makes a connection and issues a first request
- the webserver dedicates a child (or thread) to this connection, and 
passes it the first request
- the child/thread responds to the first request, and then waits for more
- the browser, in the response page, finds more links. Over the same TCP 
connection, it sends the next request
- the same child/thread - which was waiting on that connection - 
receives the new request, and responds to it. Then it waits again for 
the next one.
- etc..
- until at some point, the browser does not issue any additional 
requests on the connection. Then, *after the KeepAliveTimeout has 
expired*, the child/thread gives up, closesthe connection, and returns 
to the pool available for other requests from other browsers

So the point is, if the KeepAliveTimeout is long (like 15 seconds), it 
means that a child/thread may be kept waiting, for nothing, up to that 
many seconds, although there is nothing coming anymore.

> I however wonder if this will fix the issue. The reason being, I
> haven't changed the website code at all the past few months and there
> hasn't been any increase in the website traffic too. Hence I am unable
> to understand why we are suddenly seeing an increase in the number of
> httpd processes. The only thing I changed is the session-timeout value
> from 30 minutes to 240 minutes.
I guess that this is the Tomcat session timeout.  That should have 
nothing to do with the above.  I don't think that for Tomcat, a 
"session" is linked to a connection. It is more of a set of data saved 
somewhere, linked to the Tomcat session-id (the JSESSIONID cookie for 
instance).  Tomcar retrieves it whenever a request comes in with the 
same session-id number.  But it should not matter whether it is on the 
same TCP connection or not.

What may be linked together however, is that one request to httpd 
results in one child/thread busy with it at the Apache httpd level. If 
that request is being forwarded to Tomcat by mod_jk, then it also holds 
onto one mod_jk/Tomcat connection. This connection then holds on to one 
thread in Tomcat, until the Tomcat thread (+webapp) has supplied the 
full response. All the while, this whole chain is unavailable for other 
requests.  Thus, if there are many such requests under way, many Apache 
children/threads are busy, and Apache httpd will start additional ones 
(up to its limit) to service new requests that come in.
So if for some reason, your Tomcat requests now take longer to be 
serviced, that should also, by retro-effect, increase the number of 
httpd children/threads being started.
The bottleneck would be in Tomcat, but it would show up at the httpd level.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message