在pgbench进行了大量事务后，数据库暂时断开。

Question

我使用(PostgreSQL) 9.2.1并使用pgbench测试数据库。

pgbench -h 192.168.39.38 -p 5433 -t 1000 -c 40 -j 8 -C -U admin testdb

当我使用-C参数(为每个事务建立一个新连接)时，事务总是在16381事务之后丢失。

Connection to database "testdb" failed
could not connect to server: Can't assign requested address
    Is the server running on host "192.168.39.38" and accepting
    TCP/IP connections on port 5433?
Client 19 aborted in establishing connection.
Connection to database "testdb" failed
could not connect to server: Can't assign requested address
    Is the server running on host "192.168.39.38" and accepting
    TCP/IP connections on port 5433?
Client 19 aborted in establishing connection.
....

transaction type: TPC-B (sort of)
scaling factor: 30
query mode: simple
number of clients: 40
number of threads: 8
number of transactions per client: 1000
number of transactions actually processed: 16381/40000
tps = 1665.221801 (including connections establishing)
tps = 9487.779510 (excluding connections establishing)

在每个测试中，实际处理的事务的数总是16381。但是，pgbench可以成功，所有事务都是在以下情况下处理的：

不使用-C

或

交易总额少于16381。

删除这些事务后，数据库可以在几秒钟内继续接受连接。我想知道我是否错过了PostgreSQL的一些配置。

谢谢

编辑我发现客户端被阻塞了几秒钟来连接，但是其他的仍然可以访问数据库。这是否意味着同一个客户端不能在短时间内发送太多事务？

Answer 1

我找到了它在大约16000次交易后失去连接的原因。TCP wait_time承担了这个错误的责任。以下命令将显示TCP连接的状态：

$ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

尽管如此，它没有在MAC中显示TIME_WAIT，因此我错过了它。通过以下命令调整TCP wait_time之后，pgbench就可以正常工作了。

$ sudo sysctl -w net.inet.tcp.msl=1500
net.inet.tcp.msl: 15000 -> 1500

谢谢你的帮助。

Answer 2

实际上，操作系统施加了最大连接的限制。阅读文档中的最大连接：(粗体相关部分)

确定到数据库服务器的最大并发连接数。缺省值通常为100个连接，但如果内核设置不支持它(如initdb中所确定的那样)，可能会更少。此参数只能在服务器启动时设置。 增加此参数可能会导致PostgreSQL请求更多System共享内存或信号量，超出操作系统默认配置所允许的范围。有关如何调整这些参数的信息，如有必要，请参见第17.4.1节。

您只能打开16381个连接，这可以解释为2^14 (=16384)可能的最大连接减去默认为超级用户连接保留的3个连接(参见文档)。

Answer 3

有趣的是，16381是如此接近2的幂。

这主要是猜测：

我想知道这是不是操作系统的问题。查看TPS数据，是否为每个事务创建了一个新的连接？编辑是的，现在我已经正确地阅读了你的问题。

也许操作系统只有那么多的连接资源可以使用，并且它不能立即创建一个新的连接后，作出了16381 (加上一些额外的)在最近的？

可能有一个OS设置来指定要提供的连接资源的数量，这可能允许使用更多的连接。你能给这个问题加上一些操作系统的细节吗？

特别是，我怀疑您连接的端口号一直在增加，并且达到了极限。试试"lsof -i“，看看你是否能在发生时捕捉到一个连接，看看这个数字是否在上升。