Re: SOMAXCONN (was Re: Solaris source code)
| От | Tom Lane |
|---|---|
| Тема | Re: SOMAXCONN (was Re: Solaris source code) |
| Дата | |
| Msg-id | 15682.994804581@sss.pgh.pa.us обсуждение |
| Ответ на | Re: SOMAXCONN (was Re: Solaris source code) (ncm@zembu.com (Nathan Myers)) |
| Ответы |
Re: SOMAXCONN (was Re: Solaris source code)
Re: SOMAXCONN (was Re: Solaris source code) Re: SOMAXCONN (was Re: Solaris source code) |
| Список | pgsql-hackers |
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?
regards, tom lane
В списке pgsql-hackers по дате отправления: