apache被BT拖得连接数满

今天上午访问apache2正常，但晚上访问非常非常慢。
ps aux|grep apache|wc -l
发现进程数为152，修改
/etc/apache2/apache2.conf
将


    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    MaxClients          150
    MaxRequestsPerChild   0


其中的MaxClients由150改为250，然后/etc/init.d/apache2 reload，重读配置，速度看来不错了，但很快连接数又满了，于是查看/var/log/apache2/error.log，发觉有大量的BT访问，

[Thu Nov 26 20:18:21 2009] [error] [client 222.174.253.6] Invalid URI in request \x13BitTorrent protocolex
[Thu Nov 26 20:18:23 2009] [error] [client 60.168.17.117] Invalid URI in request \x13BitTorrent protocolex
[Thu Nov 26 20:18:26 2009] [error] [client 58.37.212.123] Invalid method in request \x9b\xa2\xa9\x82\xfc\x7f[Thu Nov 26 20:18:29 2009] [error] [client 60.168.17.117] Invalid URI in request \x13BitTorrent protocolex
[Thu Nov 26 20:18:32 2009] [error] [client 113.252.178.245] Invalid method in request %\x88\xf9g\xe8\x1a\xaf"\x95T\x1d\xffok6\xb7<\xccd~\xb4wp\xe3k-a@\xf3/\x01\xc6Z\xfe\x83$y^\x03l\x14\xf0Yr\xc0\xa1\xfbd\x82u\x07\x10\x14\x05\xda!\xedn\xbc\xa3\x1b\xdd\xa6\xaf\xe654@
[Thu Nov 26 20:18:35 2009] [error] [client 222.174.253.6] Invalid URI in request \x13BitTorrent protocolex
[Thu Nov 26 20:18:51 2009] [error] [client 219.76.127.213] Invalid method in request =\xc9\x02u\xfaj\xf6
[Thu Nov 26 20:18:53 2009] [error] [client 218.72.28.202] Invalid method in request \x83y\xe7\xf5Hw%\xab\x96\x04\x07"c\x84S\x9c\xf2I.5\x05qK)\x99\xc9\xa1Y\xc6\xdeM54\xd2_>\xb2b\x9b\xfe\xaez\x97\xf7\xb6

不知道是哪个BT软件带来的，于是在/etc/apache2/mods-enabled/setenvif.conf的段中加入
SetEnvIfNoCase Request_URI "BitTorrent" BT
然后在/etc/apache2/conf.d/apache2-doc的Directory段中加入
Deny from env=BT
要注意Order allow,deny这样的语句，逗号后面的语句总会覆盖前面的，无论实际语句谁在前。关于这个可以参见
http://blog.csdn.net/zc2087/archive/2009/07/29/4389113.aspx
摘抄一部分：


判断原则分4步走——
1.首先判断默认的；
2.然后判断逗号前的；
3.最后判断逗号后的；
4.最终按顺序叠加而得出判断结果。
上面三点我说的简单而形象，主要是为了便于记忆。暂时不理解不要紧，继续看下面详细的解说自然会明白。下面以一个普通例子来做解释——
order deny,allow
allow from 218.20.253.2
deny from 218.20
1.所谓“首先判断默认的”，就是判断“order deny,allow”这句，它默认是允许所有；
2.所谓“然后判断逗号前的”，因为在本例子中的order语句里面，deny在逗号的前面，所以现在轮到判断下面的deny语句了——“deny from 218.20”；
3.所谓“最后判断逗号后的”，因为在本例子中的order语句里面，allow在逗号的后面，所以最后轮到判断下面的allow语句了——“allow from 218.20.253.2”。
4.所谓“最终按顺序叠加而得出判断结果”，这是一个形象化了的说法，我把每一步判断都看作一个“不透明的图层”，然后一步步按顺序叠加上去，最终得出的“图像”就是判断结果。

好，现在重启apache，
/etc/init.d/apache2 restart
观察了一会儿，连接还是慢慢增多，但是并没有达到上限，后来又减少了，在100多。网站访问正常，看来解决了吧。
虽然在access.log中有大量的
::1 - - [26/Nov/2009:21:36:28 +0800] "OPTIONS * HTTP/1.0" 200 152 "-" "Apache/2.2.12 (Ubuntu) (internal dummy connection)"
但是据查，这个没什么影响，是apache2.2之后采用prefork模式时，apache进程间的通信时的虚连接。见这篇文章：
http://beacon.blog.51cto.com/442731/116222
其中说：

internal dummy connection的产生是因为apache的MPM模块用prefork方式工作，而用worker MPM则不会使用pipe of death在进程间通信，也就不会有internal dummy connections的问题。

解决办法为在配置中加入
SetEnvIf Remote_Addr "::1" dontlog
CustomLog "|/usr/local/sbin/cronolog /www/logs/XXX/access%Y%m%d.log"
combined env=!dontlog

因为这个也没多少影响，所以未对此作修改。