我得到这个错误：EADDRINUSE，当使用摇篮和CouchDB压力testingNode.js时，地址已经在使用了吗？
我正在尝试使用摇篮作为数据库驱动程序来测量带有CouchDB后端的简单Node.js程序的吞吐量。 当我把负载对程序，我得到在30秒内的以下错误：
EADDRINUSE，地址已经在使用中
这是我的程序：
var http = require ('http'), url = require('url'), cradle = require('cradle'), c = new(cradle.Connection)('127.0.0.1',5984,{cache: false, raw: false}), db = c.database('testdb'), port=8081; http.createServer(function(req,res) { var id = url.parse(req.url).pathname.substring(1); db.get(id,function(err, doc) { res.writeHead(200,{'Content-Type': 'application/json'}); res.write(JSON.stringify(doc)); res.end(); }); }).listen(port); console.log("Server listening on port "+port); 我正在使用具有50个并发用户的JMeter脚本。 平均响应时间为120ms，文件平均大小为3KB。
正如你所看到的，我把Cradle的caching设置为false。 为了调查我查看了等待套接字的数量：它增加到了大约4000，在这一点上它崩溃了（netstat | grep WAIT | wc -l）
为了testing其他选项，我将caching设置为true。 在这种情况下，程序不会崩溃，但随着时间的推移，等待套接字的数量将增加到几乎10000。
我也用Java Servlet编写了相同的程序（不含asynchronous部分），并且运行正常，没有等待套接字的数量增加到20以上。
我的问题是：为什么我得到'EADDRINUSE，地址已经在使用'错误？ 为什么等待sockets的数量如此之高？
PS：这是从netstat | grep WAIT输出的一个片段：
tcp4 0 0 localhost.5984 localhost.58926 TIME_WAIT tcp4 0 0 localhost.5984 localhost.58925 TIME_WAIT tcp4 0 0 localhost.58924 localhost.5984 TIME_WAIT tcp4 0 0 localhost.58922 localhost.5984 TIME_WAIT tcp4 0 0 localhost.5984 localhost.58923 TIME_WAIT
你确定你没有8001上的僵尸进程？
ps aux | grep node
可能有帮助
还写了一篇文章，以帮助人们开始与节点和couchdb，如果你有兴趣，你可以检查出http://writings.nunojob.com/2011/09/getting-started-with-nodejs-and-couchdb.html
升级到摇篮0.5.6。 它没有问题。
关于这个问题的猜测
等待的套接字可能处于CLOSE_WAIT状态 。 （还有其他的状态可以匹配你的grep ，比如TIME_WAIT ，你能确认它是CLOSE_WAIT而不是其他任何东西吗？）
链接的post有一个有用的报价：
RF793说CLOSE_WAIT是等待本地应用程序释放套接字的TCP / IP堆栈。 所以，它会挂起，因为它已经收到远程主机已经发起断开连接的信息，并且正在closures它的套接字，而本地应用程序没有closures它自己的一面。
所以也许解决scheme在于为您的应用程序find一个错误修复程序。
确实。 在你的情况下，每个查询有两个连接，一个从JMeter到Node，另一个从Node到CouchDB。 JMeter（旧的更成熟的软件）没有正确地closures连接，或者摇篮（较新的，较不成熟的软件）没有正确closures连接。 显然，摇篮是最有可能有错误。 （也许是NodeJS的HTTP库本身，但摇篮似乎是第一个检查的地方。）
我没有一个完整的答案，但希望这些将有帮助的线索。 我认为地址在使用中的错误是因为没有更多的源地址来作出“传出”（即使是127.0.0.1）连接。 但是我很不确定为什么每个试验中的CLOSE_WAIT计数是不同的。 （也许整个连接池closures后，可能会波动很大。）
要获得更多信息，可以尝试替代CouchDB客户端库（如request或nano）并比较结果。
请让我们知道你find了什么，因为这将是很好的识别和closures这个潜在的摇篮bug（或至less在某处的错误！）。 谢谢。