none
windows server 2008 文件服务器不定期出现大量CLOSE_WAIT状态的连接,必须重启服务器,客户端才能访问共享。 RRS feed

  • 问题

  • 故障现象如题,用netstat -ano -p tcp 可以看到大量的连接。都处于close_wait状态。。然后客户端访问共享就很卡,EXCEL也卡死。服务器重启恢复正常,但是过一段时间又出现这个问题。不知道有谁知道这个问题可能出在哪里,服务器是2008 ent sp2,客户端是XP SP3,excel 为2007版。

      TCP    172.16.5.20:445        10.188.82.17:1929      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.82.18:2400      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.82.18:2423      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.82.18:2436      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.82.18:2438      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.82.18:2443      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.82.18:2502      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.82.18:2508      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.82.18:2515      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.82.18:2539      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.82.24:1835      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.82.24:1851      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.82.24:1859      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.82.24:1873      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.82.24:2005      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.82.24:2010      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.82.37:2103      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.82.37:2112      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.84.20:3424      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.84.20:3434      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.84.20:3447      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.84.20:3467      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.84.22:1031      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.84.22:1056      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.84.22:1079      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.84.22:4977      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.85.44:3610      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.85.44:3618      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.85.64:4293      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.85.69:4203      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.85.69:4245      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.85.69:4266      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.85.83:1065      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.85.101:2771     CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.85.101:2777     CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.85.101:2782     CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.85.135:1590     CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.85.135:1598     CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.85.247:2785     CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.86.15:3120      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.86.21:1129      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.86.21:1165      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.86.21:1181      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.86.21:1183      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.86.21:1189      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.86.21:1192      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.86.21:1194      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.86.21:1200      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.86.21:1202      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.86.21:1208      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.86.21:1216      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.86.21:1224      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.86.21:1226      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.86.21:1232      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.86.21:1234      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.86.21:1240      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.86.91:1775      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.86.113:1692     CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.86.113:1694     CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.87.55:1615      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.87.73:4175      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.87.73:4178      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.87.73:4184      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.87.73:4189      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.87.73:4192      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.87.73:4194      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.87.73:4200      CLOSE_WAIT      4
      TCP    172.16.5.20:445        10.188.87.73:4202      CLOSE_WAIT      4

    
    2013年4月23日 8:53

全部回复

  • 故障当时,这些CLOSE_WAIT状态的TCP会话对应的客户端那边netstat是什么状况?

    你的Client到Server之间的网络状况良好吗?不是低速Internet下的VPN隧道互连吧?

    2013年4月23日 9:16
  • 故障当时,客户端面那边是fin_wait2的状态。CLIENT与server之间网络是好的。服务器所在地全都是千兆网络,分部与总部之间是100兆光纤VPN接入。故障发生时在服务器上看到的网络流量也就5、60兆。只是那个close_wait连接数一断的大量增长,且不关闭,服务器就停止共享服务了(远程桌面之类的其它服务正常)。。。只能重启,试过重启workstation服务没用。
    2013年4月23日 9:24
  • 那好,继续问问题了解情况。

    1、你的Server上,出现大量CLOSE_WAIT,都是在445端口上吗?(即SMB文件共享服务)

    2、你的这些客户端机器上,是否有自己开发的通过SMB去访问服务器的程序?还是仅仅都是普通的Windows自带的Explorer去对共享文件夹的访问?

    3、出问题时,这些客户端IP有规律吗?是否为一小部分特定机器?(比如,发生过3次故障,发现总是这几个客户端IP)

    2013年4月24日 3:45
  • 1、都是在445端口

    2、没有自己开发的,就是WINDOWS自带的,通过\\172.16.5.20去访问

    3、倒是没有专门去统计是否每次都是相同的客户端,但是有个规律就是只要出现这种情况,所有出现在CLOSE_WAIT连接里面的电脑就会很卡,特别是EXCEL。基本上就不能干活了。。但是到那些电脑上去看,查不出病毒或木马。

    有个情况是:前段时间,公司有部分电脑中过K4宏病毒,全部杀过了,已经没有这个病毒了,而且在组策略里禁止了对excel的startup的访问权限,不让这种病毒自动运行。按理说,应该不是这个问题,因为那个病毒并不会去访问共享,只是收集邮件地址发送有病毒的附件而已。所以现在很奇怪,为什么这些电脑会突然出现这种不正常的网络连接,而且没法重置它们。。

    2013年4月24日 6:14
  • 嗯,那么从表面现象(Server端处于CLOSE_WAIT,同时客户端处于FIN_WAIT2)来看,是客户端主动关闭TCP连接,发出了第一个FIN后,Server端ACK掉了,但Server端没再紧接着走下去(发FIN)

    这里,有一个怀疑,你的服务器网卡及驱动是否支持TCP Chimey Offload并且处于启用状态?问题发生时,可以给netstat加上-t参数,例如netstat -ano -p tcp -t来看一下Offload状态。

    由于网卡驱动兼容TCP Chimney Offload是比较常见的网络问题,建议你尝试禁用SNP,再看问题是否还会重现。

    netsh int tcp set global chimney=disable
    netsh int tcp set global rss=disable
    netsh int tcp set global netdma=disable
    reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" /v EnableTCPChimney   /t REG_DWORD /d 0 /f
    reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" /v EnableRSS          /t REG_DWORD /d 0 /f
    reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" /v EnableTCPA         /t REG_DWORD /d 0 /f
    reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" /v DisableTaskOffload /t REG_DWORD /d 1 /f

    2013年4月24日 7:01
  • 好的,谢谢。

    根据你的提示,我找了篇文档看了一下相关的解释,等出现这个现象的时候执行“-t”命令看看是什么状态。

    地址是:http://support.microsoft.com/kb/951037/en-us

    2013年4月24日 8:38