使用“此套接字已关闭”错误消息关闭与postgres的连接

时间:2012-03-14 16:16:22

标签: postgresql node.js express node-postgres

我正在向node.js 0.6.12迁移,现在使用pg模块(版本0.6.14)时出现以下错误消息:

Error: This socket is closed.
at Socket._write (net.js:453:28)
at Socket.write (net.js:446:15)
at [object Object]._send (/home/luc/node_modules/pg/lib/connection.js:102:24)
at [object Object].flush (/home/luc/node_modules/pg/lib/connection.js:192:8)
at [object Object].getRows (/home/luc/node_modules/pg/lib/query.js:112:14)
at [object Object].prepare (/home/luc/node_modules/pg/lib/query.js:150:8)
at [object Object].submit (/home/luc/node_modules/pg/lib/query.js:97:10)
at [object Object]._pulseQueryQueue (/home/luc/node_modules/pg/lib/client.js:166:24)
at [object Object].query (/home/luc/node_modules/pg/lib/client.js:193:8)
at /home/luc/test/routes/user.js:23:29

我的代码中显示的行是:

var get_obj = client.query("SELECT id FROM users WHERE name = $1", [name]);

这种用法可以与节点0.4.8和gp 0.5.0一起使用,但现在我正在测试迁移。

我在网上看到了几个像这样的错误,但没有回答。

更新

这似乎与我处理postgres连接的方式有关。今天我在运行应用程序时创建了一个连接。我认为在每个请求上创建一个新连接会更好。是否是在快速中间件中创建连接的最佳解决方案?

1 个答案:

答案 0 :(得分:2)

通常,框架和中间件会保持连接打开(或者:连接池)。问题很可能在于您的node.js代码(或用法)。顺便说一句:如果你有权访问postgres的日志文件,你可能会看到与node.js的明显断开连接。 (log_connections和log_disconnections都应设置为True以查看此内容)

Connect + disconnect被认为是一项昂贵的操作(TCP流量,授权,分支工作进程(用于postgres),会话设置,日志记录,(记帐?))。但如果它适合你(或者你只有一个请求+回复会话),那没关系。

成本/资源使用估算值

对于会话设置:

  • TCP / IP连接设置:2 * 2 IP数据包:= 4 *往返延迟
  • 登录/密码:
    • 2 * 2 TCP readwrites:= 4 *往返延迟
    • 4个系统读/写呼叫
    • 用户授权的一些​​数据库查询/查找(例如10 ... 100个磁盘读取;主要是缓存)
    • 会话构建:= fork(for postgres)+正在克隆的大量COW页面(?100-1000 pagefaults?)
  • 会话初始化:=几次往返

查询:

  • 发送+接收查询:=一些TCP / IP往返
  • parse:=一些(1 ... 100)目录查找(主要来自磁盘缓存)
  • 执行:= xxx磁盘读取(可能来自缓存)
  • 获取并存储结果:=分配(脏)缓冲区
  • 发送结果:= xxx TCP往返
  • discard result-buffers:=(几乎是免费的!)

会话拆解:

  • 3 * 2 IP往返
  • 子进程的exit(),父进程的wait()(对不起,我想用unix-terms; - )
  • 1个套接字描述符,处于TIME_WAIT状态,持续几秒/分钟

正如您所看到的,在连接建立上花费的资源量是10,可能是典型查询+结果的成本的100倍;如果您有多个查询要执行,那么保持连接打开是明智的。 (或维持一个开放的连接池)

为简单起见,我忽略了CPU消耗,主要忽略了内存/缓冲区的使用。如今,CPU似乎几乎是免费的;等待磁盘(10 ms)或网络(x ms)时可以完成的计算量是不可思议的:每个字节有几个(100 ... 10K?)滴答。