我们有Windows 2008 Datacenter SP2 64位版本的问题。 我们有一个非常频繁的轮询过程，build立新的TCP连接。 系统进入处于TIME_WAIT状态的16k以上的连接状态。 默认的操作系统超时是120秒，之后这些连接应该消失，但从来没有发生过。 即使始发过程已经终止，这些连接仍然存在并且永远不会被清除（在进程被终止两天后，我们仍然处于16k连接）。 操作系统是应该计时，但它没有。
有没有其他人看到这种行为，如果是这样做了解决它。 我们知道如何调整tcp堆栈，以缩短超时或允许更多的连接，但这不是问题在这里。
谢谢！
亚马逊EC2有这个主要问题。 他们最近修复了这个错误。 也许同样的问题适用于你的情况？
嗨，我粘贴下面是什么导致这个问题的解释。 好消息是，我们的工程团队最近已经解决了这个问题。 为了解决问题，您只需停止/启动出现此问题的Windows Server 2008实例。 再次，我不是在谈论REBOOT，这是不同的。 停止/开始导致实例移动到不同的（健康的）主机。 当这些实例再次启动时，它们将在具有修复程序的主机上运行，这样他们就不会再遇到这个问题。 下面是这个问题的工程解释。 经过深入调查，我们发现在大多数可用的实例types上运行Windows 2008 x64时，我们发现了一个问题，可能导致TCP连接在TIME_WAIT / CLOSE_WAIT中保留时间过长（在某些情况下，无限期地保持这种状态）。 在这些状态下，特定的套接字对将保持不可用状态，如果足够累积，将导致端口耗尽。 如果出现这种情况，解决问题的唯一方法就是重新引导相关实例。 我们已经确定原因是Windows 2008内核API中的定时器函数产生的值，在我们的许多64位平台上，它们偶尔会检索一个非常远的值。 这会影响TCP堆栈，因为TCP套接字对上的时间戳未来将被标记得相当远。 据微软称，除非这个API调用产生的值大于累积值，否则存储的累计计数器将不会被更新。 最终的结果是，在这一点之后创build的套接字将在未来的时间被打上太远，直到达到未来的时间。 在某些情况下，我们已经看到这个价值数百天的未来，因此套接字似乎永远卡住。
有一篇微软文章介绍了几种解决这个问题的方法。 它通常来自应用程序编码严重，不正确closures端口。 您需要查看已安装的应用程序或正在执行的任务，并禁用这些任务以查看导致问题的原因。
为了解决这个问题，你想要查看一下;
我有与Windows 2003服务器相同的问题。 当我在registryTCPIP参数更改后重新启动计算机时，问题解决了。可能是您可以尝试在服务器2008年
我注意到，如果在Intel或AMD Magny-Cours VMware服务器上部署相同的VM（Windows 2008r2），则此问题会有所不同。 在AMD上，连接停留在TIME_WAIT，在英特尔机器上，它们遵守标准的4分钟TIME_WAIT超时。