ngx_postgresql 模块的并发超时问题

haitaosoft · 2016-01-13T11:55:44+00:00

Hello,在 2016年1月13日上午10:08，Nero.Ping <kyt...@gmail.com>写道：各位&#x597D...

ngx_postgresql 模块的并发超时问题

haitaosoft

我在尝试使用 ngx_postgresql 模块实现nginx直接访问pgsql，但在测试时发现并发略多就很容易出现502或504错误（超时或连接太多）

访问涉及的sql执行都很快，基本都在几百毫秒之类

按理说，即使真的有个别查询慢，模块也可以使用其它空闲的数据库连接

即使所有连接暂时都忙，模块也可以等待几秒

但是测试的结果是部分请求直接报错，主要是2种错误，见后

（试验原因：想用它们搭建一个通用的client/webserver架构的数据库接口（rest，web api）

不同公司的所有项目系统的所有应用（浏览器、win桌面、手机应用），都通过它实现对自己所需的数据库的访问

前端应用<----------(https)---------->nginx+ngx_pgsql<---->pgsql

这个架构，多年来一直以isapi运行在iis或apache的方式在通过服务

但希望能借助于nginx的性能，提供更高的服务效率

）

实际测试环境如下：

centos7_64运行于win7下的vmware12:

Linux 192.168.204.130 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

nginx version: openresty/1.9.3.2

postgresql-9.5.0-1-linux-x64.run

测试模拟查询（win7下的桌面程序）连续发出几十到一千个curl.exe请求，请求间隔从0到150毫秒

查询的记录集内容（json格式）小于2k字节时，基本都能全部正确返回

大于2k字节之后，容易出现504错误

nginx的error.log如下：

主要是2种错误：

【

2016/01/12 14:12:03 [error] 2060#0: *3285 postgres: connection failed: FATAL: sorry, too many clients already

while connecting to PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select%20*%20from%20tbtestitem%20order%20by%20fid%20%20limit%20200;%20--970 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"

】

和

【

2016/01/09 19:45:56 [error] 6300#0: *7729 upstream timed out (110: Connection timed out) while waiting for result from PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select%20*%20from%20tbtestitem%20order%20by%20fid%20desc%20limit%201000;%20--6 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"

】

nginx的配置如下：

。。。

http {

upstream pgdb {

postgres_server 192.168.204.101 dbname=dbpos

user=uuuu password=pppp;

postgres_keepalive max=1024 mode=multi overflow=reject;

}

include mime.types;

default_type application/octet-stream;

sendfile on;

#tcp_nopush on;

#keepalive_timeout 0;

keepalive_timeout 65;

#gzip on;

server {

listen 80;

server_name localhost;

rds_json_content_type text/plain;

rds_json on;

rds_json_format compact;

location /opensql001 {

set_unescape_uri $sql $arg_sql;

postgres_connect_timeout 120s;

postgres_pass pgdb;

postgres_query $sql;

}

location /runsql001 {

set_unescape_uri $sql $arg_sql;

postgres_pass pgdb;

postgres_query $sql;

}

。。。

pgsql的配置如下：

。。。

port = 5432 # (change requires restart)

max_connections = 100 # (change requires restart)

。。。

其它基本都是默认的

麻烦你有空帮忙分析检查一下，会是什么原因导致的。

haitaosoft

wd

postgresql 的日志你看了么？最大连接数配置的是多少？

2016-01-13 11:55 GMT+08:00 haitaosoft <hait...@163.com>:

我在尝试使用 ngx_postgresql 模块实现nginx直接访问pgsql，但在测试时发现并发略多就很容易出现502或504错误（超时或连接太多）
访问涉及的sql执行都很快，基本都在几百毫秒之类
按理说，即使真的有个别查询慢，模块也可以使用其它空闲的数据库连接
即使所有连接暂时都忙，模块也可以等待几秒
但是测试的结果是部分请求直接报错，主要是2种错误，见后

（试验原因：想用它们搭建一个通用的client/webserver架构的数据库接口（rest，web api）
不同公司的所有项目系统的所有应用（浏览器、win桌面、手机应用），都通过它实现对自己所需的数据库的访问
前端应用<----------(https)---------->nginx+ngx_pgsql<---->pgsql
这个架构，多年来一直以isapi运行在iis或apache的方式在通过服务
但希望能借助于nginx的性能，提供更高的服务效率
）

实际测试环境如下：
centos7_64运行于win7下的vmware12:
Linux 192.168.204.130 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
nginx version: openresty/1.9.3.2
postgresql-9.5.0-1-linux-x64.run

测试模拟查询（win7下的桌面程序）连续发出几十到一千个curl.exe请求，请求间隔从0到150毫秒
查询的记录集内容（json格式）小于2k字节时，基本都能全部正确返回
大于2k字节之后，容易出现504错误

nginx的error.log如下：
主要是2种错误：
【
2016/01/12 14:12:03 [error] 2060#0: *3285 postgres: connection failed: FATAL: sorry, too many clients already
while connecting to PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select%20*%20from%20tbtestitem%20order%20by%20fid%20%20limit%20200;%20--970 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"
】
和
【
2016/01/09 19:45:56 [error] 6300#0: *7729 upstream timed out (110: Connection timed out) while waiting for result from PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select%20*%20from%20tbtestitem%20order%20by%20fid%20desc%20limit%201000;%20--6 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"
】

nginx的配置如下：
。。。
http {

upstream pgdb {
postgres_server 192.168.204.101 dbname=dbpos
user=uuuu password=pppp;
postgres_keepalive max=1024 mode=multi overflow=reject;
}

include mime.types;
default_type application/octet-stream;

sendfile on;
#tcp_nopush on;

#keepalive_timeout 0;
keepalive_timeout 65;

#gzip on;

server {
listen 80;
server_name localhost;

rds_json_content_type text/plain;
rds_json on;
rds_json_format compact;

location /opensql001 {
set_unescape_uri $sql $arg_sql;

postgres_connect_timeout 120s;
postgres_pass pgdb;
postgres_query $sql;
}

location /runsql001 {
set_unescape_uri $sql $arg_sql;

postgres_pass pgdb;
postgres_query $sql;
}
。。。

pgsql的配置如下：
。。。
port = 5432 # (change requires restart)
max_connections = 100 # (change requires restart)
。。。
其它基本都是默认的

麻烦你有空帮忙分析检查一下，会是什么原因导致的。

haitaosoft

--

haitaosoft

pgsql的日志是：

2016-01-12 21:50:56 CST LOG: database system was shut down at 2016-01-12 21:38:54 CST

2016-01-12 21:50:56 CST LOG: MultiXact member wraparound protections are now enabled

2016-01-12 21:50:56 CST LOG: database system is ready to accept connections

2016-01-12 21:50:56 CST LOG: autovacuum launcher started

2016-01-12 22:15:17 CST FATAL: sorry, too many clients already

后面的都是这种失败

配置是：

。。。

# - Connection Settings -

listen_addresses = '*' # what IP address(es) to listen on;

# comma-separated list of addresses;

# defaults to 'localhost'; use '*' for all

# (change requires restart)

port = 5432 # (change requires restart)

max_connections = 100 # (change requires restart)

# Note: Increasing max_connections costs ~400 bytes of shared memory per

# connection slot, plus lock space (see max_locks_per_transaction).

。。。

haitaosoft

发件人： wd
发送时间： 2016-01-13 14:26
收件人： openresty
主题： Re: [openresty] ngx_postgresql 模块的并发超时问题
postgresql 的日志你看了么？最大连接数配置的是多少？

2016-01-13 11:55 GMT+08:00 haitaosoft <hait...@163.com>:

我在尝试使用 ngx_postgresql 模块实现nginx直接访问pgsql，但在测试时发现并发略多就很容易出现502或504错误（超时或连接太多）
访问涉及的sql执行都很快，基本都在几百毫秒之类
按理说，即使真的有个别查询慢，模块也可以使用其它空闲的数据库连接
即使所有连接暂时都忙，模块也可以等待几秒
但是测试的结果是部分请求直接报错，主要是2种错误，见后

（试验原因：想用它们搭建一个通用的client/webserver架构的数据库接口（rest，web api）
不同公司的所有项目系统的所有应用（浏览器、win桌面、手机应用），都通过它实现对自己所需的数据库的访问
前端应用<----------(https)---------->nginx+ngx_pgsql<---->pgsql
这个架构，多年来一直以isapi运行在iis或apache的方式在通过服务
但希望能借助于nginx的性能，提供更高的服务效率
）

实际测试环境如下：
centos7_64运行于win7下的vmware12:
Linux 192.168.204.130 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
nginx version: openresty/1.9.3.2
postgresql-9.5.0-1-linux-x64.run

测试模拟查询（win7下的桌面程序）连续发出几十到一千个curl.exe请求，请求间隔从0到150毫秒
查询的记录集内容（json格式）小于2k字节时，基本都能全部正确返回
大于2k字节之后，容易出现504错误

nginx的error.log如下：
主要是2种错误：
【
2016/01/12 14:12:03 [error] 2060#0: *3285 postgres: connection failed: FATAL: sorry, too many clients already
while connecting to PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select%20*%20from%20tbtestitem%20order%20by%20fid%20%20limit%20200;%20--970 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"
】
和
【
2016/01/09 19:45:56 [error] 6300#0: *7729 upstream timed out (110: Connection timed out) while waiting for result from PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select%20*%20from%20tbtestitem%20order%20by%20fid%20desc%20limit%201000;%20--6 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"
】

nginx的配置如下：
。。。
http {

upstream pgdb {
postgres_server 192.168.204.101 dbname=dbpos
user=uuuu password=pppp;
postgres_keepalive max=1024 mode=multi overflow=reject;
}

include mime.types;
default_type application/octet-stream;

sendfile on;
#tcp_nopush on;

#keepalive_timeout 0;
keepalive_timeout 65;

#gzip on;

server {
listen 80;
server_name localhost;

rds_json_content_type text/plain;
rds_json on;
rds_json_format compact;

location /opensql001 {
set_unescape_uri $sql $arg_sql;

postgres_connect_timeout 120s;
postgres_pass pgdb;
postgres_query $sql;
}

location /runsql001 {
set_unescape_uri $sql $arg_sql;

postgres_pass pgdb;
postgres_query $sql;
}
。。。

pgsql的配置如下：
。。。
port = 5432 # (change requires restart)
max_connections = 100 # (change requires restart)
。。。
其它基本都是默认的

麻烦你有空帮忙分析检查一下，会是什么原因导致的。

haitaosoft

--

--

wd

2016-01-13 15:30 GMT+08:00 haitaosoft <hait...@163.com>:

2016-01-12 22:15:17 CST FATAL: sorry, too many clients already

这个错误很明显哦，连接数太多了。

如果你 db 机器硬件允许的话，调整下最大连接数。

haitaosoft

现在配置是已经100个连接了。。。。

数据库的连接肯定比不上高峰时的前端的请求数啊

【按理说，即使真的有个别查询慢，模块也可以使用其它空闲的数据库连接

即使所有连接暂时都忙，模块也可以等待几秒】

假设每个请求的数据库的平均费时是300ms，而模块最多能等3秒，

那就可以让数据库的连接数只有最高请求数的1/10 时，就能应付过来

ngx_postgresql在这方面有没有等待的机制？

haitaosoft

发件人： wd
发送时间： 2016-01-13 16:10
收件人： openresty
主题： Re: Re: [openresty] ngx_postgresql 模块的并发超时问题

2016-01-13 15:30 GMT+08:00 haitaosoft <hait...@163.com>:
2016-01-12 22:15:17 CST FATAL: sorry, too many clients already

这个错误很明显哦，连接数太多了。
如果你 db 机器硬件允许的话，调整下最大连接数。

haitaosoft

把pgsql的最大连接数改为1200

port = 5432 # (change requires restart)

max_connections = 1200 # (change requires restart)

重启服务

nginx的配置还是1024

upstream pgdb {

postgres_server 192.168.204.101 dbname=dbpos

user=postgres password=yyyhht;

postgres_keepalive max=1024 mode=multi overflow=reject;

# postgres_connect_timeout 300s;

# postgres_output text;

}

连续发1000个curl.exe访问，仍然出现很多504错误

pgsql日志没错误了

nginx的错误是：

2016/01/13 16:44:18 [error] 2429#0: *1235 upstream timed out (110: Connection timed out) while waiting for result from PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select%20*%20from%20tbtestitem%20order%20by%20fid%20%20limit%20600;%20--995 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"

2016/01/13 16:44:18 [error] 2429#0: *1241 upstream timed out (110: Connection timed out) while waiting for result from PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select%20*%20from%20tbtestitem%20order%20by%20fid%20%20limit%20600;%20--1000 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"

haitaosoft

发件人： wd
发送时间： 2016-01-13 16:10
收件人： openresty
主题： Re: Re: [openresty] ngx_postgresql 模块的并发超时问题

2016-01-13 15:30 GMT+08:00 haitaosoft <hait...@163.com>:
2016-01-12 22:15:17 CST FATAL: sorry, too many clients already

这个错误很明显哦，连接数太多了。
如果你 db 机器硬件允许的话，调整下最大连接数。

--

chen.wei37

应该隔离测试下，找个对pgsql加压的工具单独测试pgsql性能看看有没问题，如果没问题说明问题在NGINX上。

另外连续发1000个curl.exe---这个是并行还是串行？怎么连续发的CURL

发件人: haitaosoft <hait...@163.com>
收件人: openresty <openresty@googlegroups.com>,
日期: 2016/01/13 16:53
主题: Re: Re: [openresty] ngx_postgresql 模块的并发超时问题
发件人: openresty@googlegroups.com

把pgsql的最大连接数改为1200
port = 5432 # (change requires restart)
max_connections = 1200 # (change requires restart)
重启服务

nginx的配置还是1024
upstream pgdb {
postgres_server 192.168.204.101 dbname=dbpos
user=postgres password=yyyhht;
postgres_keepalive max=1024 mode=multi overflow=reject;
# postgres_connect_timeout 300s;
# postgres_output text;
}

连续发1000个curl.exe访问，仍然出现很多504错误
pgsql日志没错误了
nginx的错误是：
2016/01/13 16:44:18 [error] 2429#0: *1235 upstream timed out (110: Connection timed out) while waiting for result from PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select%20*%20from%20tbtestitem%20order%20by%20fid%20%20limit%20600;%20--995 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"
2016/01/13 16:44:18 [error] 2429#0: *1241 upstream timed out (110: Connection timed out) while waiting for result from PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select%20*%20from%20tbtestitem%20order%20by%20fid%20%20limit%20600;%20--1000 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"

haitaosoft

发件人： wd
发送时间： 2016-01-13 16:10
收件人： openresty
主题： Re: Re: [openresty] ngx_postgresql 模块的并发超时问题

2016-01-13 15:30 GMT+08:00 haitaosoft <hait...@163.com>:
2016-01-12 22:15:17 CST FATAL: sorry, too many clients already

这个错误很明显哦，连接数太多了。
如果你 db 机器硬件允许的话，调整下最大连接数。


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

moonbingbing

你配置的worker数是多少？

postgres_keepalive max=1024 这个是单个worker的，如果你设置了10个worker，那就等于是10240。

在 2016年1月13日下午4:52，haitaosoft <hait...@163.com>写道：

把pgsql的最大连接数改为1200
port = 5432 # (change requires restart)
max_connections = 1200 # (change requires restart)
重启服务

nginx的配置还是1024
upstream pgdb {
postgres_server 192.168.204.101 dbname=dbpos
user=postgres password=yyyhht;
postgres_keepalive max=1024 mode=multi overflow=reject;
# postgres_connect_timeout 300s;
# postgres_output text;
}

连续发1000个curl.exe访问，仍然出现很多504错误
pgsql日志没错误了
nginx的错误是：
2016/01/13 16:44:18 [error] 2429#0: *1235 upstream timed out (110: Connection timed out) while waiting for result from PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select%20*%20from%20tbtestitem%20order%20by%20fid%20%20limit%20600;%20--995 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"
2016/01/13 16:44:18 [error] 2429#0: *1241 upstream timed out (110: Connection timed out) while waiting for result from PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select%20*%20from%20tbtestitem%20order%20by%20fid%20%20limit%20600;%20--1000 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"

haitaosoft

发件人： wd
发送时间： 2016-01-13 16:10
收件人： openresty
主题： Re: Re: [openresty] ngx_postgresql 模块的并发超时问题

2016-01-13 15:30 GMT+08:00 haitaosoft <hait...@163.com>:
2016-01-12 22:15:17 CST FATAL: sorry, too many clients already

这个错误很明显哦，连接数太多了。
如果你 db 机器硬件允许的话，调整下最大连接数。

--

--

haitaosoft

#user nobody;

worker_processes 1;

#error_log logs/error.log;

#error_log logs/error.log notice;

#error_log logs/error.log info;

#pid logs/nginx.pid;

events {

worker_connections 1024;

}

haitaosoft

发件人： Ming
发送时间： 2016-01-13 17:08
收件人： openresty@googlegroups.com
主题： Re: Re: [openresty] ngx_postgresql 模块的并发超时问题
你配置的worker数是多少？
postgres_keepalive max=1024 这个是单个worker的，如果你设置了10个worker，那就等于是10240。

在 2016年1月13日下午4:52，haitaosoft <hait...@163.com>写道：

把pgsql的最大连接数改为1200
port = 5432 # (change requires restart)
max_connections = 1200 # (change requires restart)
重启服务

nginx的配置还是1024
upstream pgdb {
postgres_server 192.168.204.101 dbname=dbpos
user=postgres password=yyyhht;
postgres_keepalive max=1024 mode=multi overflow=reject;
# postgres_connect_timeout 300s;
# postgres_output text;
}

连续发1000个curl.exe访问，仍然出现很多504错误
pgsql日志没错误了
nginx的错误是：
2016/01/13 16:44:18 [error] 2429#0: *1235 upstream timed out (110: Connection timed out) while waiting for result from PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select%20*%20from%20tbtestitem%20order%20by%20fid%20%20limit%20600;%20--995 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"
2016/01/13 16:44:18 [error] 2429#0: *1241 upstream timed out (110: Connection timed out) while waiting for result from PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select%20*%20from%20tbtestitem%20order%20by%20fid%20%20limit%20600;%20--1000 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"

haitaosoft

发件人： wd
发送时间： 2016-01-13 16:10
收件人： openresty
主题： Re: Re: [openresty] ngx_postgresql 模块的并发超时问题

2016-01-13 15:30 GMT+08:00 haitaosoft <hait...@163.com>:
2016-01-12 22:15:17 CST FATAL: sorry, too many clients already

这个错误很明显哦，连接数太多了。
如果你 db 机器硬件允许的话，调整下最大连接数。

--

--

--

haitaosoft

最后的测试，pgsql没报错日志，应该是nginx就连到数据库了

由一个GUI程序循环1000次启动带命令行的curl.exe

其实真正的并发数肯定远小于1000的

2016-01-13 16:43:34.737

1:r:\work\exe\curl.exe -s "http://192.168.204.101/。。。

20:r:\work\exe\curl.exe -s "http://192.168.204.101/。。。

...

980:r:\work\exe\curl.exe -s "http://192.168.204.101/。。。

1000:r:\work\exe\curl.exe -s "http://192.168.204.101/。。。

2016-01-13 16:43:45.688

haitaosoft

发件人： chen.wei37
发送时间： 2016-01-13 17:00
收件人： openresty
主题： 答复: Re: Re: [openresty] ngx_postgresql 模块的并发超时问题
应该隔离测试下，找个对pgsql加压的工具单独测试pgsql性能看看有没问题，如果没问题说明问题在NGINX上。

另外连续发1000个curl.exe---这个是并行还是串行？怎么连续发的CURL

agentzh

Hello!

2016-01-13 0:52 GMT-08:00 haitaosoft:
> 连续发1000个curl.exe访问，仍然出现很多504错误
> pgsql日志没错误了
> nginx的错误是：
> 2016/01/13 16:44:18 [error] 2429#0: *1235 upstream timed out (110:
> Connection timed out) while waiting for result from PostgreSQL database,
> client: 192.168.204.1, server: localhost, request: "GET
> /opensql001?sql=select%20*%20from%20tbtestitem%20order%20by%20fid%20%20limit%20600;%20--995
> HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host:
> "192.168.204.101"

这里有两种可能性哈：

1. 你的 postgresql 服务器确实是性能瓶颈，确实有查询超时。

2. 你的 postgresql 自带的 libpq 客户端库在边沿触发的事件模式下，非阻塞操作的状态机有 bug.

为确认是否是第 2 点，你可以试试在 nginx.conf 的 events {} 里面添加下面这一行

    use poll;

即让 nginx 使用水平触发的 poll 事件接口。如果没问题的话，咱们就可以确认是 2) 成立。

当然，你需要在编译 NGINX 或者 OpenResty 时，指定 ./configure 选项 --with-poll_module.
因为 NGINX 或者 OpenResty 默认是没有 poll 接口的支持的。

Regards,
-agentzh

agentzh

Hello!

2016-01-13 10:35 GMT-08:00 Yichun Zhang (agentzh):
> 这里有两种可能性哈：
>
> 1. 你的 postgresql 服务器确实是性能瓶颈，确实有查询超时。
>
> 2. 你的 postgresql 自带的 libpq 客户端库在边沿触发的事件模式下，非阻塞操作的状态机有 bug.
>
> 为确认是否是第 2 点，你可以试试在 nginx.conf 的 events {} 里面添加下面这一行
>
>     use poll;
>
> 即让 nginx 使用水平触发的 poll 事件接口。如果没问题的话，咱们就可以确认是 2) 成立。
>
> 当然，你需要在编译 NGINX 或者 OpenResty 时，指定 ./configure 选项 --with-poll_module.
> 因为 NGINX 或者 OpenResty 默认是没有 poll 接口的支持的。
>

另外，值得一提的是，你也可以尝试一下基于 ngx_lua 非阻塞的 cosocket API 的 PostgreSQL 客户端驱动，比如
leafo 同学的 pgmoon 库：

    https://github.com/leafo/pgmoon

Regards,
-agentzh

haitaosoft

下载openresty最新版本，加入poll配置编译，再测试真的没问题了！

pgsql配置的最大连接数由1200改为100，也没出现504错误了。

难道真的是pgsql的libpq有bug？

记得先编译安装了一个9.4版本，最近9.5出来后，直接下载安装了一个run

不过客户端库可能还是9.2.14的。。。。

同一台机器，服务端已经是9.4、9.5了，不知道怎么让客户端也升级为9.5

为了更新pgsql客户端，搜到一个apt-get更新的，于是去找centos下的apt。。。

【➜ shm rpm -i apt-0.5.15lorg3.94a-5.el5.rf.x86_64.rpm

error: Failed dependencies:

libreadline.so.5()(64bit) is needed by apt-0.5.15lorg3.94a-5.el5.rf.x86_64

librpm-4.4.so()(64bit) is needed by apt-0.5.15lorg3.94a-5.el5.rf.x86_64

librpmdb-4.4.so()(64bit) is needed by apt-0.5.15lorg3.94a-5.el5.rf.x86_64

librpmio-4.4.so()(64bit) is needed by apt-0.5.15lorg3.94a-5.el5.rf.x86_64

➜ shm rpm -i apt-devel-0.5.15lorg3.94a-5.el5.rf.x86_64.rpm

error: Failed dependencies:

apt = 0.5.15lorg3.94a-5.el5.rf is needed by apt-devel-0.5.15lorg3.94a-5.el5.rf.x86_64

libapt-pkg.so.3()(64bit) is needed by apt-devel-0.5.15lorg3.94a-5.el5.rf.x86_64

————【除了apt的便捷以外，apt-get的一大好处是极大地减小了所谓依赖关系恶梦的发生几率(dependency hell)，即使是陷入了dependency hell，apt-get也提供了很好的援助手段，帮你逃出魔窟。】

】

额外问一句：poll的效率极高

为什么nginx不是以poll为默认方式，而是要重新编译才支持？

应该默认编译支持poll，实际是否采用，才通过配置来决定

haitaosoft

发件人： Yichun Zhang (agentzh)
发送时间： 2016-01-14 02:35
收件人： openresty
主题： Re: Re: [openresty] ngx_postgresql 模块的并发超时问题
Hello!

2016-01-13 0:52 GMT-08:00 haitaosoft:

> 连续发1000个curl.exe访问，仍然出现很多504错误

> pgsql日志没错误了

> nginx的错误是：

> 2016/01/13 16:44:18 [error] 2429#0: *1235 upstream timed out (110:

> Connection timed out) while waiting for result from PostgreSQL database,

> client: 192.168.204.1, server: localhost, request: "GET

> /opensql001?sql=select%20*%20from%20tbtestitem%20order%20by%20fid%20%20limit%20600;%20--995

> HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host:

> "192.168.204.101"

这里有两种可能性哈：

1. 你的 postgresql 服务器确实是性能瓶颈，确实有查询超时。

2. 你的 postgresql 自带的 libpq 客户端库在边沿触发的事件模式下，非阻塞操作的状态机有 bug.

为确认是否是第 2 点，你可以试试在 nginx.conf 的 events {} 里面添加下面这一行

use poll;

即让 nginx 使用水平触发的 poll 事件接口。如果没问题的话，咱们就可以确认是 2) 成立。

当然，你需要在编译 NGINX 或者 OpenResty 时，指定 ./configure 选项 --with-poll_module.

因为 NGINX 或者 OpenResty 默认是没有 poll 接口的支持的。

Regards,

-agentzh

--

--

邮件来自列表“openresty”,专用于技术讨论!

订阅: 请发空白邮件到 openresty+subscribe@googlegroups.com

发言: 请发邮件到 openresty@googlegroups.com

退订: 请发邮件至 openresty+unsubscribe@googlegroups.com

归档: http://groups.google.com/group/openresty

官网: http://openresty.org/

仓库: https://github.com/agentzh/ngx_openresty

教程: http://openresty.org/download/agentzh-nginx-tutorials-zhcn.html

agentzh

Hello!

2016-01-13 18:23 GMT-08:00 haitaosoft:
> 下载openresty最新版本，加入poll配置编译，再测试真的没问题了！
> pgsql配置的最大连接数由1200改为100，也没出现504错误了。
> 难道真的是pgsql的libpq有bug？

是的，PostgreSQL 的 libpq 的非阻塞接口的实现不够健壮，对于边沿触发的事件模型有已知的
bug，会导致其处理状态机陷于无限等待。我们以前就遇到过。

> 记得先编译安装了一个9.4版本，最近9.5出来后，直接下载安装了一个run
> 不过客户端库可能还是9.2.14的。。。。
> 同一台机器，服务端已经是9.4、9.5了，不知道怎么让客户端也升级为9.5
> 为了更新pgsql客户端，搜到一个apt-get更新的，于是去找centos下的apt。。。

你可以尝试从官方最新的源码直接编译 libpq，但我不确定官方最新的 libpq 是否真的就没有问题了，呵呵。

>
> 额外问一句：poll的效率极高
> 为什么nginx不是以poll为默认方式，而是要重新编译才支持？
> 应该默认编译支持poll，实际是否采用，才通过配置来决定
>

poll 的效率其实还不够高，否则大家就不必再搞 kqueue, epoll 这些高级的事件接口了，呵呵。

Nginx 在 Linux 上面默认只编译效率最高的 epoll 接口，而 *BSD 风格的系统上则只编译那些平台上最高效的 kqueue
接口。只有在 Windows 上目前默认使用 select，效率还不及 poll，呵呵。

Regards,
-agentzh

moonbingbing

我们的 Windows 版本上也一直有这个问题。因为有很多其他程序的数据库慢查询，所以就没往这个方面想。

还是用 cosocket 的方式靠谱。

在 2016年1月14日上午10:45，Yichun Zhang (agentzh) <age...@gmail.com>写道：

Hello!

2016-01-13 18:23 GMT-08:00 haitaosoft:
> 下载openresty最新版本，加入poll配置编译，再测试真的没问题了！
> pgsql配置的最大连接数由1200改为100，也没出现504错误了。
> 难道真的是pgsql的libpq有bug？

是的，PostgreSQL 的 libpq 的非阻塞接口的实现不够健壮，对于边沿触发的事件模型有已知的
bug，会导致其处理状态机陷于无限等待。我们以前就遇到过。

> 记得先编译安装了一个9.4版本，最近9.5出来后，直接下载安装了一个run
> 不过客户端库可能还是9.2.14的。。。。
> 同一台机器，服务端已经是9.4、9.5了，不知道怎么让客户端也升级为9.5
> 为了更新pgsql客户端，搜到一个apt-get更新的，于是去找centos下的apt。。。

你可以尝试从官方最新的源码直接编译 libpq，但我不确定官方最新的 libpq 是否真的就没有问题了，呵呵。

>
> 额外问一句：poll的效率极高
> 为什么nginx不是以poll为默认方式，而是要重新编译才支持？
> 应该默认编译支持poll，实际是否采用，才通过配置来决定
>

poll 的效率其实还不够高，否则大家就不必再搞 kqueue, epoll 这些高级的事件接口了，呵呵。

Nginx 在 Linux 上面默认只编译效率最高的 epoll 接口，而 *BSD 风格的系统上则只编译那些平台上最高效的 kqueue
接口。只有在 Windows 上目前默认使用 select，效率还不及 poll，呵呵。

Regards,
-agentzh

--

haitaosoft

>poll 的效率其实还不够高，否则大家就不必再搞 kqueue, epoll 这些高级的事件接口了，呵呵。

>Nginx 在 Linux 上面默认只编译效率最高的 epoll 接口，而 *BSD 风格的系统上则只编译那些平台上最高效的 kqueue

>接口。只有在 Windows 上目前默认使用 select，效率还不及 poll，呵呵。

哦。。。epoll才最高

那么，配置里去掉 use poll; 是不是就是epoll模式了？无须重新编译？

如果这样，倒是最合理的

haitaosoft

agentzh

Hello!

2016-01-13 19:03 GMT-08:00 haitaosoft:
> 哦。。。epoll才最高
> 那么，配置里去掉 use poll; 是不是就是epoll模式了？无须重新编译？

在 Linux 上面是这样的。

Regards,
-agentzh

haitaosoft

这两天发现又出现了502错误：已经是 use poll;

不知道这个【sorry, too many clients already while connecting to PostgreSQL database】是ngx_pgsql 还是pgsql 报的错？

ngx_pgsql有没有在pgsql连接池满的时候，再尝试等待n秒呢？（这个n有没有得配置的？）

2016/01/16 18:02:20 [error] 4077#0: *1678 postgres: connection failed: FATAL: sorry, too many clients already

while connecting to PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select...--146 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"

2016/01/16 18:02:20 [error] 4077#0: *1682 postgres: connection failed: FATAL: sorry, too many clients already

while connecting to PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select...--144 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"

2016/01/16 18:02:20 [error] 4077#0: *1686 postgres: connection failed: FATAL: sorry, too many clients already

while connecting to PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select....--246 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"

2016/01/16 18:02:20 [error] 4077#0: *1690 postgres: connection failed: FATAL: sorry, too many clients already

while connecting to PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select....--247 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"

2016/01/16 18:02:30 [error] 4077#0: *1923 postgres: connection failed: FATAL: sorry, too many clients already

while connecting to PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select....--313 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"

2016/01/16 18:02:30 [error] 4077#0: *1924 postgres: connection failed: FATAL: sorry, too many clients already

while connecting to PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select....--311 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"

2016/01/16 18:02:30 [error] 4077#0: *1926 postgres: connection failed: FATAL: sorry, too many clients already

while connecting to PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select....--320 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"

haitaosoft

发件人： Yichun Zhang (agentzh)
发送时间： 2016-01-14 10:45
收件人： openresty
主题： Re: Re: [openresty] ngx_postgresql 模块的并发超时问题
Hello!

2016-01-13 18:23 GMT-08:00 haitaosoft:

> 下载openresty最新版本，加入poll配置编译，再测试真的没问题了！

> pgsql配置的最大连接数由1200改为100，也没出现504错误了。

> 难道真的是pgsql的libpq有bug？

是的，PostgreSQL 的 libpq 的非阻塞接口的实现不够健壮，对于边沿触发的事件模型有已知的

bug，会导致其处理状态机陷于无限等待。我们以前就遇到过。

> 记得先编译安装了一个9.4版本，最近9.5出来后，直接下载安装了一个run

> 不过客户端库可能还是9.2.14的。。。。

> 同一台机器，服务端已经是9.4、9.5了，不知道怎么让客户端也升级为9.5

> 为了更新pgsql客户端，搜到一个apt-get更新的，于是去找centos下的apt。。。

你可以尝试从官方最新的源码直接编译 libpq，但我不确定官方最新的 libpq 是否真的就没有问题了，呵呵。

>

> 额外问一句：poll的效率极高

> 为什么nginx不是以poll为默认方式，而是要重新编译才支持？

> 应该默认编译支持poll，实际是否采用，才通过配置来决定

>

poll 的效率其实还不够高，否则大家就不必再搞 kqueue, epoll 这些高级的事件接口了，呵呵。

Nginx 在 Linux 上面默认只编译效率最高的 epoll 接口，而 *BSD 风格的系统上则只编译那些平台上最高效的 kqueue

接口。只有在 Windows 上目前默认使用 select，效率还不及 poll，呵呵。

Regards,

-agentzh

--

--

邮件来自列表“openresty”,专用于技术讨论!

订阅: 请发空白邮件到 openresty+subscribe@googlegroups.com

发言: 请发邮件到 openresty@googlegroups.com

退订: 请发邮件至 openresty+unsubscribe@googlegroups.com

归档: http://groups.google.com/group/openresty

官网: http://openresty.org/

仓库: https://github.com/agentzh/ngx_openresty

教程: http://openresty.org/download/agentzh-nginx-tutorials-zhcn.html

haitaosoft

根据报错日志，定位失败位置

给 bundle/ngx_postgres-1.0rc7/src/ngx_postgres_upstream.c 加上多次延时再尝试的做法（黄色背景部分）：

【

for (int iretry=0; 1; iretry++)

{

pgdt->pgconn = PQconnectStart((const char *)connstring);

if (PQsetnonblocking(pgdt->pgconn, 1) == -1) {

if (iretry<100)

{

//ngx_msleep(100);

msleep(100);

continue;

}

ngx_log_error(NGX_LOG_ERR, pc->log, 0,

"postgres: connection failed: %s in upstream \"%V\"",

PQerrorMessage(pgdt->pgconn), &peer->name);

PQfinish(pgdt->pgconn);

pgdt->pgconn = NULL;

#if defined(nginx_version) && (nginx_version >= 8017)

dd("returning NGX_DECLINED");

return NGX_DECLINED;

#else

pgctx->status = NGX_HTTP_BAD_GATEWAY;

goto failed;

#endif

}

else

break;

}

】

但是编译时又出错了：

因为之前为了让centos7的pgsql不用默认的9.2，而改用最新的9.5

可能对libpq等文件做了修改

现在重新编译openresty --with pgsql时报错了！

【

adding module in ../ngx_postgres-1.0rc7

checking for libpq library (via pg_config) ... not found

checking for libpq library ... not found

checking for libpq library in /usr/../postgresql/ ... not found

checking for libpq library in /usr/local/ ... not found

checking for libpq library in /usr/local/../postgresql/ ... not found

checking for libpq library in /usr/pkg/ ... not found

checking for libpq library in /opt/local/ ... not found

./configure: error: ngx_postgres addon was unable to find the libpq library.

ERROR: failed to run command: sh ./configure --prefix=/opt/nginx/nginx \...

】

看上面信息，它会找/usr/local/../postgresql/

但是我已经建了软连接：

ngx_openresty-1.9.7.1# ll /usr/postgresql

lrwxrwxrwx. 1 root root 14 2016-01-17 00:27:37 /usr/postgresql -> /usr/pgsql-9.5

怎么还找不到？

haitaosoft

发件人： haitaosoft
发送时间： 2016-01-16 18:13
收件人： openresty
主题： Re: Re: [openresty] ngx_postgresql 模块的并发超时问题

这两天发现又出现了502错误：已经是 use poll;
不知道这个【sorry, too many clients already while connecting to PostgreSQL database】是ngx_pgsql 还是pgsql 报的错？
ngx_pgsql有没有在pgsql连接池满的时候，再尝试等待n秒呢？（这个n有没有得配置的？）

2016/01/16 18:02:20 [error] 4077#0: *1678 postgres: connection failed: FATAL: sorry, too many clients already
while connecting to PostgreSQL database, client: 192.168.204.1, server: localhost, request: "GET /opensql001?sql=select...--146 HTTP/1.1", upstream: "postgres://192.168.204.101:5432", host: "192.168.204.101"