Interesting problem. I am running Apache 2.0.59 as a reverse proxy on multiple Solaris 9 and AIX servers and have never encountered these types of issues. Perhaps you should try upgrading to 2.0.59 on one of your development machines and see if that makes a difference. If not, it is most likely an OS and/or configuration issue. What other plugins are you running? Also, is this HTTP proxying, or HTTPS? ----- Original Message ---- From: Chirouze Olivier <olivier.chirouze@xxxxxxxxx> To: users@xxxxxxxxxxxxxxxx Sent: Friday, January 26, 2007 9:56:46 AM Subject: 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 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@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com --------------------------------------------------------------------- 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@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|