On Sat, Jul 14, 2001 at 11:38:51AM -0400, Tom Lane wrote:
>
> The state of affairs in current sources is that the listen queue
> parameter is MIN(MaxBackends * 2, PG_SOMAXCONN), where PG_SOMAXCONN
> is a constant defined in config.h --- it's 10000, hence a non-factor,
> by default, but could be reduced if you have a kernel that doesn't
> cope well with large listen-queue requests. We probably won't know
> if there are any such systems until we get some field experience with
> the new code, but we could have "configure" select a platform-dependent
> value if we find such problems.
Considering the Apache comment about some systems truncating instead
of limiting... 10000&0xff is 16. Maybe 10239 would be a better choice,
or 16383.
> So, having thought that through, I'm still of the opinion that holding
> off accept is of little or no benefit to us. But it's not as simple
> as it looks at first glance. Anyone have a different take on what the
> behavior is likely to be?
After doing some more reading, I find that most OSes do not reject
connect requests that would exceed the specified backlog; instead,
they ignore the connection request and assume the client will retry
later. Therefore, it appears cannot use a small backlog to shed load
unless we assume that clients will time out quickly by themselves.
OTOH, maybe it's reasonable to assume that clients will time out,
and that in the normal case authentication happens quickly.
Then we can use a small listen() backlog, and never accept() if we
have more than MaxBackend back ends. The OS will keep a small queue
corresponding to our small backlog, and the clients will do our load
shedding for us.
Nathan Myers
ncm@zembu.com