Hello, We're having some strange problems with our webservers (https), which are Apache 2.0.52 on RHEL4 and 2.0.46 on RHEL 3. The problem is that, under a certain load or after a while, the number of connections to one of the webservers stuck in the "W" state (as indicate by server-status?notable) steadily starts increasing. The "SS" value listed for each request on this page is very large (i.e. >> any apache timeout setting) Having searched the archives, I have found threads on DoS attacks (resulting in lots of connections in the "reading" state with little more information). The number of connections from any single ip, however, is at most 20-30 at the point where "MaxClients" connections have frozen into the "W" state (512 W's in our case). According to netstat, most of the connections to the https server are in state "ESTABLISHED" (about half), then a lot of the connections are "CLOSE_WAIT" and the remainder is in state "SYN_RECV". The Apache servers connect to Websphere 5, WebSphere 6 (Websphere plugin) and Tomcat/JBoss (mod_jk) application servers and use the CA/Netegrity Siteminder plugin. Bascially, my questions are: 1. When, exactly, is a connection listed in "W(riting)" state? Does this mean the http server has already received the necessary responses from backend application servers (if necessary)? Or can this state occur when the http server is waiting for some backend server? I'm looking to determine if maybe one of the backend plugins has not been set correctly (assuming these plugins correctly honour timeout values presented to them). 2. Has anyone experienced this kind of server behaviour, and if so, could share some thoughts on possible (trivial and non-trivial) causes, testcaeses and solutions? --------------------------------------------------------------------- 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
|