Re: Connection problem under extreme load.

Jeffery Collins <collins(at)onyx-technologies(dot)com> writes:
> We have been doing some load testing with postgresql, and we have been
> getting the following error when libpq attempts to connect to the
> backend. This only happens occasionally and, as I said under extreme
> load (e.g. load average 30+ on a single processor Sun).

> connectDBStart() -- connect() failed: Connection refused
> Is the postmaster running at 'localhost' and accepting connections on
> Unix socket '6700'?

Interesting. I *think* (not totally sure) that 'Connection refused'
here implies that the kernel rejected the connection before the
postmaster ever had a chance to do anything with it. The most likely
reason would probably be that the maximum connection backlog was
exceeded. On my system (HPUX) man listen(2) sez

int listen(int s, int backlog);

...

backlog defines the desirable queue length for pending connections.
The actual queue length may be greater than the specified backlog . If
a connection request arrives when the queue is full, the client will
receive an ETIMEDOUT error.

backlog is limited to the range of 0 to SOMAXCONN, which is defined in
<sys/socket.h>. SOMAXCONN is currently set to 20. If any other value
is specified, the system automatically assigns the closest value
within the range. A backlog of 0 specifies only 1 pending connection
is allowed at any given time.

ETIMEDOUT is not the error you are getting, but that could be a platform
difference. In fact the nearest BSD system I have access to says that
"the client will receive an error with an indication of ECONNREFUSED".
The same box defines SOMAXCONN as 5, which seems a tad low :-(

So, it would seem your options are
(a) recompile your kernel with larger SOMAXCONN, or
(b) figure out why the postmaster isn't responding faster.

Offhand, the only performance problem I know of in the postmaster is
that it does IDENT checks serially --- if you specify ident checks in
pg_hba.conf, the postmaster will wait for a response from the ident
server before processing more connection requests. So if you're using
IDENT authentication you might want to consider some other answer, or
else fix that code and send in a patch.

If that's not it, please poke into it further and let us know what you
find out.

regards, tom lane