From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Subject: | Re: profiling connection overhead |
Date: | 2010-12-06 17:55:22 |
Message-ID: | AANLkTi=stHiv3Lcnqb9_xseZ+=SX3amUEhdYYUz4mnEA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 6, 2010 at 12:38 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> One possible way to do make an improvement in this area would be to
>> move the responsibility for accepting connections out of the
>> postmaster. Instead, you'd have a group of children that would all
>> call accept() on the socket, and the OS would arbitrarily pick one to
>> receive each new incoming connection. The postmaster would just be
>> responsible for making sure that there were enough children hanging
>> around. You could in fact make this change without doing anything
>> else, in which case it wouldn't save any work but would possibly
>> reduce connection latency a bit since more of the work could be done
>> before the connection actually arrived.
>
> This seems like potentially a good idea independent of anything else,
> just to reduce connection latency: fork() (not to mention exec() on
> Windows) now happens before not after receipt of the connection request.
> However, I see a couple of stumbling blocks:
>
> 1. Does accept() work that way everywhere (Windows, I'm looking at you)
Not sure. It might be useful to look at what Apache does, but I don't
have time to do that ATM.
> 2. What do you do when max_connections is exceeded, and you don't have
> anybody at all listening on the socket? Right now we are at least able
> to send back an error message explaining the problem.
Sending back an error message explaining the problem seems like a
non-negotiable requirement. I'm not quite sure how to dance around
this. Perhaps if max_connections is exhausted, the postmaster itself
joins the accept() queue and launches a dead-end backend for each new
connection. Or perhaps we reserve one extra backend slot for a
probably-dead-end backend that will just sit there and mail rejection
notices; except that if it sees that a regular backend slot has opened
up it grabs it and turns itself into a regular backend.
> Another issue that would require some thought is what algorithm the
> postmaster uses for deciding to spawn new children. But that doesn't
> sound like a potential showstopper.
The obvious algorithm would be to try to keep N spare workers around.
Any time the number of unconnected backends drops below N the
postmaster starts spawning new ones until it gets back up to N. I
think the trick may not be the algorithm so much as finding a way to
make the signaling sufficiently robust and lightweight. For example,
I bet having each child that gets a new connection signal() the
postmaster is a bad plan.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2010-12-06 17:57:44 | Re: profiling connection overhead |
Previous Message | Andrew Dunstan | 2010-12-06 17:50:19 | Re: WIP patch for parallel pg_dump |