On Tue, 11 Feb 2003, Merlin Moncure wrote:
> Here's the comment I was referring to:
>
> /*
> * InitProcGlobal -
> * initializes the global process table. We put it here so that
> * the postmaster can do this initialization.
> *
> * We also create all the per-process semaphores we will need to
> support
> * the requested number of backends. We used to allocate
> semaphores
> * only when backends were actually started up, but that is bad
> because
> * it lets Postgres fail under load --- a lot of Unix systems are
> * (mis)configured with small limits on the number of semaphores,
> and
> * running out when trying to start another backend is a common
> failure.
> * So, now we grab enough semaphores to support the desired max
> number
> * of backends immediately at initialization --- if the sysadmin
> has set
> * MaxBackends higher than his kernel will support, he'll find
> out sooner
> * rather than later.
> *
> * Another reason for creating semaphores here is that the
> semaphore
> * implementation typically requires us to create semaphores in
> the
> * postmaster, not in backends.
> */
Interesting. I was looking at the max number of file handles, but not
semaphores. I don't have to adjust the sem settings until I break 2047
connections, about 10 times what I want to set the default to.
With max connections set to 200 and buffers set to 1000, I pretty much
can't run out of system resources on my box, only postgresql resources.
My box running RH72 has about 6500 free file handles out of the default
8192 left when running 200 simo transactions with pgbench, and the 200 max
connects setting would account for about 10% of the shared semaphore max
on the box, well under what I'd worry about.
So, what OSes would have a problem, if any, with boosting something
like max connects to 200? What are the breaking points on other OSes?
I just downloaded FreeBSD 5.0 yesterday, so I'll try to get it installed
and tested as well.
