IIS 日志记录中 Timer_ConnectionIdle 日志记录过多的问题

[ 2011-08-27 08:20:36 | 作者: admin ]
字号: | |
Connection_Abandoned_By_AppPool

错误原因:1.大多因为Web在调用外部程序的时候,外部程序运行时出错引起的。
                    2.另外有可能是Application Pool出错了 可以重新给Web项目分配一个Application Pool或者修改Application Pool的所有者 注意 所有者的用户名密码一定要正确,而且必须包含在IIS那个组里。
解决方法:调试外部程序,保证无误。

这些天发现公司的网站多了很多httperror,开始检查IIS log了,发现 IIS 里面很多Timer_ConnectionIdle和Timer_MinBytesPerSecond的错误,到网络上google了一下,常见说法是说错误是因为IIS的设置不当引起的,是因为连接超时时间设置太小,解决方法是
1.打开Internet 信息服务(IIS)管理器,右键点“我的计算机”——属性,选上“允许直接编辑配置数据库(N)”,确定。
2.设置连接超时(ConnectionTimeout)为600秒,
3.把MinFileBytesPerSec的设置从240修改到0(相当于关掉该设置)。觉得这些解决方法都有问题,假如车辆防盗警报经常响,正确的解决方法是看看有谁常来打你车子的主意,或者把车子放在更安全的地方,而绝对不是关掉警报。
            因为HTTP服务需要占用TCP连接,而TCP连接时是需要占用系统资源的,而且IIS为每个连接也需要分配相应的资源。目前的主机能够处理上万的连接就可以说是软硬件设计都很不错了(可以参见C10K )。假如恶意人员通过一台或者多台机器发起大量的连接,而不请求内容(这样不需要消耗多少攻击机器的带宽),就可以大量消耗服务器资源而达到拒绝服务的目的。

          所以 IIS 需要关闭长时间非活动的连接,这个就是Timer_ConnectionIdle 的错误由来。

          原来以为攻击者可以给服务器故意缓慢的发送和接收内容而消耗服务器的资源,这样可以避免服务器对于Timer_ConnectionIdle 的保护,相应的IIS的防范就是 MinFileBytesPerSec 设置,MinFileBytesPerSec 属性通过以最小的数据量保持连接,来禁止恶意的或软件工作不正常的客户端消耗资源。如果吞吐量低于 MinFileBytesPerSec 设置的值,则终止连接。LOG里面就会显示Timer_MinBytesPerSecond错误(一些Timer_MinBytesPerSecond错误是因为 windows 2003 的http.sys错误引起的,解决方式是打上最新 ServicePack : http://support.microsoft.com/kb/919797 http://support.microsoft.com/kb/919797/en-us

            所以说这些设置都是用来保护IIS服务器的,可以一定程度上抵御一些恶意的行为消耗服务器的资源;还有个问题是iislog日志文件不做记录日志文件特别小一直不清楚什么问题?

http://blog.csdn.net/webclass/archive/2008/01/14/2044156.aspx
评论Feed 评论Feed: http://blog.xg98.com/feed.asp?q=comment&id=1718

这篇日志没有评论。

此日志不可发表评论。