|
有一台服务器，运行sqlserver数据库，有两个网站模块的数据库在上面，负载压力不大，平时没出现过问题。后来另外一个部门放了一个网站上去，数据库也在同一台机器上,突然有天L部门反应网站访问不了了，FTP也连不上了。但数据库能够远程连接上。 远程到服务器上，FTP服务重启，无效；网站重启，无效，查看系统日志，发现有如下错误 xxx在与 SQL Server 建立连接时出现与网络相关的或特定于实例的错误。未找到或无法访问服务器。请验证实例名称是否正确并且 SQL Server 已配置为允许远程连接。 (provider: TCP Provider, error: 0 - 由于系统缓冲区空间不足或队列已满，不能执行套接字上的操作。)。 没碰到过这种情况，为了恢复服务，索性把服务器重启了，一切都好了。过了两天，又有这种情况出现。google一下，知道大概原因是端口用完了，猜测是不是L部门网站代码有问题，数据库连接泄露没关闭完？没有使用连接池？看了代码，都没问题。只好查看系统端口的使用情况： 1 命令行下输入 netstat -ano >>D://net.txt ，列出目前端口使用情况,如下大概有三千多条 ，注意红色端口的使用 TCP 222.122.222.222:2756 52.122.120.88:80 CLOSE_WAIT 2144 发现本地在访问一个外网地址的80端口，对应PID是2144 2.命令行下输入 tasklist|findstr "2144" 查看 PID对应的进程 w3wp.exe 2144 services 看起来是一个网站，这时突然想起来，不久前发布了一个webservice，主要功能是用httpwebrequest分析提取某个网站的部分内容，返回给调用方 3.命令行下输入 C:\Windows\System32\inetsrv>appcmd list wp WP "5648" (applicationPool:testmozhou) 确认问题来源，webservice多线程下，每个httpwebrequest没有及时释放问题所致 PS： 最近事情很多，人也懒，东西看了不少，也想到过一些东西，但就是懒得写。现在记录一下前两个星期做一个压力测试时出现的现象，希望重开一个好头。简 单地说，这是个从Windows Server连接Linux下的MongoDB服务时出现的问题。MongoDB使用的是自定义的二进制协议，客户端使用普通的TCP连接进行连接后再读 写数据。在以前的测试中，我使用的都是建立少量连接，每个连接进行多次操作，而这次则是对“应用程序”进行压力测试，因此需要不断地开启及关闭连接——频 率大约是每秒4、500次吧。 我使用的环境是Windows Web Server 2008 R2，MongoDB部署在Cent OS上，双方都是64位操作系统。压力测试刚开启时一切顺利，性能也比较令人满意，但是不久后便会抛出这样的异常：
一开始我以为是程序里有哪个地方没有释放连接，于是检查了程序代码，觉得没有问题；后来又直接使用mongodb-csharp进行频繁连接关闭，结果还是出现了同样的错误，于是我又怀疑是驱动本身的问题，但是看了看讨论组中似乎又没有人汇报过这个问题；于是我又换了个思路，使用了Java平台上的驱动写了个简单的测试程序，居然还是得到了这个错误。由此我确定了两点：
还有一个细节：在直接使用驱动进行插入操作的时候，发现无论使用多少线程同时进行，最终永远是在插入了16370-16380条记录之后停止，这意 味着每次都是打开关闭了确定次数之后出现的错误，这很有可能是一个操作系统限制所致的结果。因此，我使用这段错误信息在网上寻找解决方案，原因有很多，大 都不是我需要的。顺便一提，只有中文的错误信息真是很难找到合适的结果，因此我不得不通过几个关键字，再连蒙带猜地得到了错误的标准英文翻译：
有了这段信息，找起答案来就简单多了，例如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服务器我很满意。 |
|
|
