Re: Connection problem under extreme load.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Connection problem under extreme load.
Дата
Msg-id 28811.964766116@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Connection problem under extreme load.  (Jeffery Collins <collins@onyx-technologies.com>)
Список pgsql-general
Jeffery Collins <collins@onyx-technologies.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

В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: 4 billion record limit?
Следующее
От: "anuj"
Дата:
Сообщение: 'make' on Linux