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 по дате отправления: