Re: SOMAXCONN (was Re: Solaris source code) - Mailing list pgsql-hackers

From ncm@zembu.com (Nathan Myers)
Subject Re: SOMAXCONN (was Re: Solaris source code)
Date
Msg-id 20010710174936.I23310@store.zembu.com
Whole thread Raw
In response to Re: SOMAXCONN (was Re: Solaris source code)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Jul 10, 2001 at 06:36:21PM -0400, Tom Lane wrote:
> ncm@zembu.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@zembu.com


pgsql-hackers by date:

Previous
From: mlw
Date:
Subject: Re: Postgresql bulk fast loader
Next
From: Tatsuo Ishii
Date:
Subject: Re: i need help for JDBC