设为首页 收藏本站
查看: 1164|回复: 0

[经验分享] IIS故障问题(Connections_Refused)分析及处理

[复制链接]
累计签到:13 天
连续签到:1 天
发表于 2015-8-12 09:59:17 | 显示全部楼层 |阅读模式
    这篇文章其实已经写好很久,只是后来一直没有重现当时的问题,或者因为业务的重要性、投诉的压力也就临时处理了。这几天某地市Web服务器连续多次出现这个问题,正好借这个案例来做个收尾。

    前几个月有台重要的Web服务器(Windows Server2003 + IIS6.0)出现客户端无法访问Web服务器上的站点,错误信息提示为"页面无法显示"的情况。登录服务器检查后发现IIS并未停止运行,各服务也正常处理,但就是无法访问站点上的页面(包括静态页面)。这种问题其实以前也经常发生,基本上处理方法都是通过重启Web服务器来解决,至于为什么要这样处理,并没有具体的论断和依据,多半是凭借个人的经验所致,所以这种解决方法只能缓解下投诉压力,没有从根本上解决问题。

    那么,我们现在就来针对这个问题深入探讨下,找出问题的根本,争取做到治标治本。

      首先,肯定是分析问题服务器上的IIS日志,我发现在站点无法访问的那段时间, httperr日志中记录了大量的"Connections_Refused"错误

   DSC0000.jpg
     这个问题是在默认情况下,如果可用的非分页缓冲池内存不足 20MB,Http.sys 服务将停止接收新连接,就会出现上述问题。这也就解释了为什么重启IIS没用,只能通过重启Web服务器释放内存资源来解决。
     网上也有微软官方的解决方案:
  1. 进入注册表,找到如下项:
     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters ;  
  2. 新建Dword值,输入名称 "EnableAggressiveMemoryUsage";
  3. 修改值为1;
  4. 重启 HTTP 服务:
     在DOS下分别执行   
        net stop http /y
        iisreset /restart
    我按照上述说明进行了配置,但有没有效果无法考证,只能先观察这台服务器后续的运行情况。这种处理方法比之前重启Web服务器更进了一步,至少比之前盲目的重启重启重启,更明确的知道了引起问题的原因,离真相更近了一步。那么问题发生的真正原因呢?究竟是什么导致的非分页缓冲池内存会持续增大到少于20M的呢?
    要分析这个问题,首先得了解下Windows系统中的核心内存概念:核心内存是Windows分配给系统内核或驱动所需的内存空间,分页内存是虚拟内存,也就是这一部分内存可以置换到硬盘中,但是,非分页内存是不能置换到硬盘的,只能保存在物理内存中,常用于一些软件或是系统的驱动程序使用。如果未分页内存无限增大,到达一个阀值,就会造成系统问题。在32位的Windows上,这个阀值最高不能超过256MB,否则操作系统会变得非常不稳定。
    打开自己系统的任务管理器,在"性能"项中,可以看到:

   DSC0001.jpg
     如上图所示,这就是我本机当前时刻所使用的分页和未分页内存数,这个数字很正常。
     我们再来看下最近这台有问题的机器连续2天,2次出现故障时的内存使用数,未分页内存已经不知不觉暴涨到230多M了
   DSC0002.jpg
   DSC0003.jpg
        好了,废话不多说,这个时候就需要用到Poolmon这个核心内存泄漏检测工具了。通过这个工具,我们来看看Web服务器上到底是哪些软件或者程序造成内存泄露,从而导致未分页内存数不足的。Poolmon是类似于Dos 的命令行执行程序,基本上完成检测的操作我们只需要2个指令: P-排序标签列表通过分页,非分页,混合等3种模式;B-对标签排序最大字节使用情况。如下图所示:显示的就是操作系统中所有占用非分页内存项,并按字节大小降序排列。我们找出排在前面,并且字节数不断增加的tag项,根据Tag来定位进程和驱动文件。比如我们想看下目前占用90M非分页内存的Thre项,在Dos中输入:
    findstr /s /m /l "Thre" c:\windows\system32\drivers\*.sys
   DSC0004.jpg
   DSC0005.jpg
      如上图所示,我们看到是系统驱动和杀毒驱动占用了Thre。这台机器上次中过毒,所以后来下了瑞星和360卫士来排毒。瑞星是出了名的耗未分页内存大户,360卫士本身也已经被病毒感染,所以我基本锁定了这2款软件,先卸载,然后重启服务器,重新下载360卫士和360杀毒再次排毒之后观察服务器运行情况和内存消耗情况。从上次重启到目前为止,运行十多天,未分页内存总消耗保持在50M以内,虽有小许增长,但还算正常。到此,根据上面的分析, 我们就可以定位出导致IIS故障的真正问题所在了。这种问题,很大部分是因为杀毒软件程序或者一些系统驱动导致的。
    这里说的很大部分原因是因为杀毒软件程序或者一些系统驱动导致的非分页内存不足,是因为非分页内存一般是内核程序或驱动程序在请求。这种资源非常宝贵,如果程序处理不当的话,也会导致上述情况,比如一个Socket只接受连接,但因为某些原因没有读取数据,然后客户端连接上之后一直发送数据,在这种极端的情况下未分页内存也很快就会被占满。

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-97800-1-1.html 上篇帖子: 在ASP.NET MVC中使用IIS级别的URL Rewrite 下篇帖子: 【轮子狂魔】抛弃IIS,向天借个HttpListener
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表