Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
Received-SPF: pass (herse.apache.org: domain of olivier.chirouze@volvo.com
 designates 192.138.110.232 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 26 Jan 2007 16:56:46 +0100
Message-ID: 
 <CE67133097F05C4B938A5482E32525E2023724A1@segotn647.vcn.ds.volvo.net>
Thread-Topic: Apache 2.0.58 + Solaris 5.9: status "...reading..." & TCP state
 "FIN_WAIT_2"
Thread-Index: AcdBYpUEzG75cCS4SZ+dKSYCExzOog==
From: "Chirouze Olivier" <olivier.chirouze@volvo.com>
To: <users@httpd.apache.org>
Subject: [users@httpd] Apache 2.0.58 + Solaris 5.9: status "...reading..." &
 TCP state "FIN_WAIT_2"

Hi all,

I'm facing a quite tricky situation with Apache 2.0.58 running on
Solaris 5.9.

Apache is running as a reverse proxy (mod_proxy + mod_rewrite).
The maximum concurrent connections is set to 150.

Because we reached the maximum a few times and got the reverse proxy
saturated, we started monitoring the Apache status page (/status).
We noticed that many requests were in the "..reading.." state (up to
40!), and they block a lot of slots.

At first, we upgraded from 2.0.47 to 2.0.58 because it seemed there was
a security hole in the earlier, fixed in 2.0.48.
I found some explanation here:
http://www.monkeybrains.net/~rudy/example/server_busy_state.html.

The thing is, the situation is starting to appear again with 2.0.58.

We've gone down to Unix and found that most of these requests were in
"FIN_WAIT_2" TCP state, and for a while (approx. 8min!!).

We found this: http://httpd.apache.org/docs/2.0/misc/fin_wait_2.html.
What it says, in a word, is that these things can happen and are
"normal": the connection stays in "FIN_WAIT_2" state until the timeout,
if clients do not close it properly. They just say it can be a problem
on the Unix point of view because.
I don't know if this is still true for 2.0 because the article was just
copied from 1.3. The thing is, it says that "The connections in
FIN_WAIT_2 do not tie up an httpd process". For us, IT DOES! Every
"..reading.." request happend to be in the "FIN_WAIT_2" state.

We have contacted Sun to get their opinion. The short answer is "you can
change the FIN_WAIT_2 timeout but be careful because wrong tuning will
have negative impact. Maybe you should wonder why these connections stay
alive". As far as I understood, the connection is not closed by the
client. The server (Apache) does nothing wrong. But maybe it does, as it
doesn't leave the process free?

My questions are:
Does anyone have heard about similar problems?
Why do these connections hold a process of Apache while the
documentation says it doesn't?
Do you recon tuning the Unix timeout would help? (current value of
tcp_fin_wait_2_flush_interval: 675000 ms - 11min!! This looks just
huge!)

Thanks in advance,

Olivier

Olivier CHIROUZE
I&0 Infrastructure
=20
Volvo Information Technology


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org