An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full.
与 SQL Server 建立连接时出现与网络相关的或特定于实例的错误。未找到或无法访问服务器。请验证实例名称是否正确并且 SQL Server 已配置为允许远程连接。 (provider: TCP Provider, error: 0 - 由于系统缓冲区空间不足或队列已满，不能执行套接字上的操作。)。
1 命令行下输入 netstat -ano >>D://net.txt ，列出目前端口使用情况,如下大概有三千多条 ，注意红色端口的使用
TCP 222.122.222.222:2756 52.122.120.88:80 CLOSE_WAIT 2144
TCP 222.122.222.222:2766 52.122.120.88:80 CLOSE_WAIT 2144
TCP 222.122.222.222:2776 52.122.120.88:80 CLOSE_WAIT 2144
TCP 222.122.222.222:2786 52.122.120.88:80 CLOSE_WAIT 2144
TCP 222.122.222.222:2796 52.122.120.88:80 CLOSE_WAIT 2144
TCP 222.122.222.222:2806 52.122.120.88:80 CLOSE_WAIT 2144
TCP 222.122.222.222:2816 52.122.120.88:80 CLOSE_WAIT 2144
TCP 222.122.222.222:2828 52.122.120.88:80 CLOSE_WAIT 2144
TCP 222.122.222.222:2838 52.122.120.88:80 CLOSE_WAIT 2144
TCP 222.122.222.222:2851 52.122.120.88:80 CLOSE_WAIT 2144
TCP 222.122.222.222:2860 52.122.120.88:80 CLOSE_WAIT 2144
TCP 222.122.222.222:2870 52.122.120.88:80 CLOSE_WAIT 2144
.......
发现本地在访问一个外网地址的80端口，对应PID是2144
这里可以直接到任务管理器里面查看PID对应进程
2.命令行下输入 tasklist|findstr "2144" 查看 PID对应的进程
w3wp.exe 2144 services
3.命令行下输入 C:\Windows\System32\inetsrv>appcmd list wp
WP "5648" (applicationPool:testmozhou)
WP "5664" (applicationPool:tqh.xxx.cn)
WP "1544" (applicationPool:www.lxxxg.com)
WP "2144" (applicationPool:data.tt.com)
确认问题来源，webservice多线程下，每个httpwebrequest没有及时释放问题所致
PS：
最近事情很多，人也懒，东西看了不少，也想到过一些东西，但就是懒得写。现在记录一下前两个星期做一个压力测试时出现的现象，希望重开一个好头。简单地说，这是个从Windows Server连接Linux下的MongoDB服务时出现的问题。MongoDB使用的是自定义的二进制协议，客户端使用普通的TCP连接进行连接后再读写数据。在以前的测试中，我使用的都是建立少量连接，每个连接进行多次操作，而这次则是对“应用程序”进行压力测试，因此需要不断地开启及关闭连接——频率大约是每秒4、500次吧。
我使用的环境是Windows Web Server 2008 R2，MongoDB部署在Cent OS上，双方都是64位操作系统。压力测试刚开启时一切顺利，性能也比较令人满意，但是不久后便会抛出这样的异常：
由于系统缓冲区空间不足或队列已满，不能执行套接字上的操作。
一开始我以为是程序里有哪个地方没有释放连接，于是检查了程序代码，觉得没有问题；后来又直接使用mongodb-csharp进行频繁连接关闭，结果还是出现了同样的错误，于是我又怀疑是驱动本身的问题，但是看了看讨论组中似乎又没有人汇报过这个问题；于是我又换了个思路，使用了Java平台上的驱动写了个简单的测试程序，居然还是得到了这个错误。由此我确定了两点：
- 这很可能不是mongodb-csharp这个驱动程序的问题。当然，要确定这一点还需要更多测试，例如在mono上使用这个驱动。
- 这是操作系统方面的问题，因为.NET和Java都给出了同样的错误信息，甚至和当前程序的语言文化设置无关。
还有一个细节：在直接使用驱动进行插入操作的时候，发现无论使用多少线程同时进行，最终永远是在插入了16370-16380条记录之后停止，这意味着每次都是打开关闭了确定次数之后出现的错误，这很有可能是一个操作系统限制所致的结果。因此，我使用这段错误信息在网上寻找解决方案，原因有很多，大都不是我需要的。顺便一提，只有中文的错误信息真是很难找到合适的结果，因此我不得不通过几个关键字，再连蒙带猜地得到了错误的标准英文翻译：
An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full.
有了这段信息，找起答案来就简单多了，例如KB上找到了这样一条记录，说是在Windows Vista及2008中，Tcp/IP动态端口的范围调整到49152至65535，做一个简单的减法可以发现我们可以使用16384个接口，和我们之前看到的记录数量大致相同，基本可以确定是频繁地打开关闭操作造成客户端的动态端口用尽的问题。KB上也给出了解决方法，只要使用netsh命令便可以进行设置。
不过有意思的是，我在此之前还找到了另一条记录，说是在HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters下面可以增加一个MaxUserPort参数，指定程序可以使用的端口范围，它的默认值是5000，也就是端口范围是1025至5000，这也是上一条记录中说Windows之前的端口策略，它的“适用范围”已经不包括2008系统，但我鬼使神差地将MaxUserPort设置为65534（十进制）之后，原本只能插入16000多条记录的程序已经能够插入数万条，这意味着修改的确生效了。
当然，这么做还是没有解决问题，总不见得插入这么多条记录之后还是失败吧。其实第二条记录里还写到，有一个TcpTimedWaitDelay参数，表示一个关闭后的端口等待多久之后可以重新使用，顺着这个信息我找到了《TCP/IP Registry Values for Windows Server 2008》这样一篇文章，描述Vista与2008系统中各种TCP/IP相关的参数，其中自然包括了TcpTimedWaitDelay，它的默认值为120，表示端口关闭后120秒才能重新使用。
于是我们来算一下，假设有60000个端口可用，如果在120秒内消耗完毕，则每秒最多使用500个端口，这远远低于MongoDB的性能瓶颈，甚至接近了一个Web应用程序的需求——根据压力测试，我们单台Web服务器每秒可以处理接近200个动态请求，这意味着平均每个请求只能使用2.5个连接。根据文档，我将TcpTimedWaitDelay设成最短的30秒，这意味着我们可以每秒开启关闭2000个端口，平均每个请求使用10个连接。够了。
这个问题就这样解决了，说实话很简单，也就是个“知道就能解决”的配置问题。当然现在这个方式并不算太理想，更好的方式应该是利用连接池，这样便不会开启/关闭大量的TCP/IP连接，默认的端口数量也已经足够了，更重要的是这也可以省下很大的开销——因为经过测试，即使是最复杂的ASP.NET页面，只要不涉及MongoDB，每秒也能处理6500多个请求，而目前每秒200个动态请求，从数字上看也远低于MongoDB的能力，我们有理由相信目前的性能似乎是卡在连接的打开/关闭上了。
只可惜目前mongodb-csharp的连接池实现有bug，用于清理连接的维护进程居然会让造成明显的中断，甚至在频繁使用十几分钟后还抛出了异常。有机会的话我再看看吧，但我总觉得它目前的实现过于复杂了，我估计都可以说是面向对象的“经典”使用案例了。
最后再来一提，话说我目前使用的是64位的Windows Web Server 2008 R2系统，功能强大，价格便宜，授权宽松，最多允许使用到32GB内存，作为Web服务器我很满意。
PS：文章只做个人保存学习使用
转自：http://www.360doc.com/content/15/0414/10/22908209_463085108.shtml
