登录
Microsoft.com
 
Microsoft
 
 
 

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

 > 

  • 问题

  • Question
    登录进行投票
    0
    登录进行投票

    故障现象如题，用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
    |

全部回复

  • Question
    登录进行投票
    0
    登录进行投票

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

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

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

    那好，继续问问题了解情况。

    1、你的Server上，出现大量CLOSE_WAIT，都是在445端口上吗？（即SMB文件共享服务）

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

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

    2013年4月24日 3:45
    |
  • Question
    登录进行投票
    0
    登录进行投票

    1、都是在445端口

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

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

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

    2013年4月24日 6:14
    |
  • Question
    登录进行投票
    0
    登录进行投票

    嗯，那么从表面现象（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
    |
  • Question
    登录进行投票
    0
    登录进行投票

    好的，谢谢。

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

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

    2013年4月24日 8:38
    |
  • Question
    登录进行投票
    0
    登录进行投票
    How to know if TCP offload is working
    http://blogs.technet.com/b/brad_rutkowski/archive/2007/08/10/how-to-know-if-tcp-offload-is-working.aspx
    2013年4月24日 8:57
    |