From: | ncm(at)zembu(dot)com (Nathan Myers) |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SOMAXCONN (was Re: Solaris source code) |
Date: | 2001-07-11 00:49:36 |
Message-ID: | 20010710174936.I23310@store.zembu.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 10, 2001 at 06:36:21PM -0400, Tom Lane wrote:
> ncm(at)zembu(dot)com (Nathan Myers) writes:
> > All the OSes we know of fold it to 128, currently. We can jump it
> > to 10240 now, or later when there are 20GHz CPUs.
>
> > 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?
I don't think the issue is the resources that are consumed by the
accept-queue entry. Rather, it's a tuning knob to help shed load
at the entry point to the system, before significant resources have
been committed. An administrator would tune it according to actual
system and traffic characteristics.
It is easy enough for somebody to change, if they care, that it seems
to me we have already devoted it more time than it deserves right now.
Nathan Myers
ncm(at)zembu(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Ian Lance Taylor | 2001-07-11 00:51:38 | Re: SOMAXCONN (was Re: Solaris source code) |
Previous Message | mlw | 2001-07-11 00:41:21 | Re: Postgresql bulk fast loader |