Tom Lane <tgl@sss.pgh.pa.us> writes:
> ncm@zembu.com (Nathan Myers) writes:
> > If you want to make it more complicated, it would be more useful to
> > be able to set the value lower for runtime environments where PG is
> > competing for OS resources with another daemon that deserves higher
> > priority.
>
> Hmm, good point. Does anyone have a feeling for the amount of kernel
> resources that are actually sucked up by an accept-queue entry? If 128
> is the customary limit, is it actually worth worrying about whether
> we are setting it to 128 vs. something smaller?
Not much in the way of kernel resources is required by an entry on the
accept queue. Basically a socket structure and maybe a couple of
addresses, typically about 200 bytes or so.
But I wouldn't worry about it, and I wouldn't worry about Nathan's
suggestion for making the limit configurable, because Postgres
connections don't spend time on the queue. The postgres server will
be picking them off as fast as it can. If the server can't pick
processes off fast enough, then your system has other problems;
reducing the size of the queue won't help those problems. A large
queue will help when a large number of connections arrives
simultaneously--it will permit Postgres to deal them appropriately,
rather than causing the system to discard them on its terms.
(Matters might be different if the Postgres server were written to not
call accept when it had the maximum number of connections active, and
to just leave connections on the queue in that case. But that's not
how it works today.)
Ian
---------------------------(end of broadcast)---------------------------
TIP 842: "When the only tool you have is a hammer, you tend to treat
everything as if it were a nail."
-- Abraham Maslow