A post I found on another forum, maybe this thing is worth reading ... there are 2 parts from this same guy ... read below ...
################ This might be long but shows something I must have missed ... and I'm sure the solution is simple On a Plesk intel sys I am having this serious problem that might affect any form posting page (years back this was a classic DOS attack but Apache has patched this ages ago ) --- Simple php script that does simple select * from (page is a total of 30k so needs couple of seconds loading). A Form on that page submits on itself. Pressing regularly the Submit button acts as usual (page returns ok). You can see the rest ... banging like crasy on that Submit creates a fifo Mysql Sleep queue and blocks connections with apache . *** Now wait .. dont answer yet this is tougher than that *** _pconnect or _connect have the same effect I placed php non persistent .. the same Apache keep_alive=Off .. the same Mysqld variables wait_timeout was reduced (I saw the sleep status by mysqladmin, and the growing sleep threads). After this timeout the sleep threads were killed but ressources not freed. Same thig with wait_timeout. So I got serious ... netstat shows that on every mysql sleep a socket was opened with the script (thats just the way it should be since a child forks on the page) but the child stays at TIME_WAIT or some ACK state. Seems as if apache cant detect closed socket from client (pipe sig or whatever) * mysqld restart WONT free the connections (it's apache's fault) * httpd restart does the trick since all blocking children are killed and the browser behaves as usual (reproducing every time the stuff above) * mod_throttle also does the trick since I limit to 1 Concurrent connection.. but that sux I have been on this for 14 hours now without coffee or sweets , so please someone tell me the one and only line i have to place in a config file to resolve this mess thanx ---- Configs are : php 4.0.6 (basic Plesk install) Apache 1.3.19 (Plesk install) mod_perl, mod_throttle, mod_php4, mod_frontpage, mod_ssl, mod_setenvif, mod_so, mod_unique_id, mod_usertrack, mod_headers, mod_expires, mod_cern_meta, mod_proxy, mod_digest, mod_auth_dbm, mod_auth_anon, mod_auth, mod_access, mod_rewrite, mod_alias, mod_userdir, mod_speling, mod_actions, mod_imap, mod_asis, mod_cgi, mod_dir, mod_autoindex, mod_include, mod_info, mod_status, mod_negotiation, mod_mime, mod_mime_magic, mod_log_config, mod_define, mod_env, mod_vhost_alias, http_core Mysql 3.23.36 ################ The second post : ################ I ripped inside out that script and got out of it what follows for people who want to know : the _connect is done in an include file, look at the snip here : ****** include(); mysql_query(); print(); // 16k long The blocking happens with the above ****** When I make the _connect inside the same script file (without include() ), I NO longer get the apache blocking but my TCP stack continues growing with CLOSE_WAIT sockets (one for each reload)... totaly nuts since it's the same thing as before but mysql does no longer queue sleep threads .. this is outerspace... BETTER : when i reduce that print() of 16k to less (like 1 k) I NO longer get socket CLOSE_WAITS and all works ok What it means to me : Under mod_php if all buffer flushes have not been done before a die() (another reload) and another apache fork is made (or child select()), ressources are NOT freed. To make sure of this I placed a mysql_close();sleep(2) just before the long print(). mod_php had then the time to close much more sockets than if I left the sleep(2) out.. but still some CLOSE_WAITS were maid. All this was on IE and Netscape. The problem is as you said, If I get a DOS attack my comp will die, even worse If I have huge hits since TCP stack will reach MaxClients and apache will refuse connect(). That's it -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
