Trevor Talbot wrote:
> On 10/20/07, Rainer Bauer <usenet@munnin.com> wrote:
>
>> Anyway, the problem are the no. of semaphores created by Postgres:
>> Every backend creates at least 4*<max_connections> semaphores. Just
>> increase <max_connections> to an unusual high value (say 10000) and
>> start creating new connections while monitoring the handle count.
>
> Hmm, they're actually the same semaphores, so the only cost is for
> slots in each process's handle table, which comes from kernel paged
> pool. Testing shows I can easily create about 30 million handles to a
> given object on this machine. This is under win2003 with 1.25GB RAM,
> which gives it a paged pool limit of 352MB.
>
> I tried going up to 20000 max_connections, and still blew postmaster's
> VM space long before paged pool was exhausted. I couldn't test any
> higher values, as there's some interaction between max_connections and
> shared_buffers that prevents it from mapping the buffer contiguously.
>
> Something's missing though, since I'm not hitting the same issue you
> are. How are you generating the connections? I just have an app
> calling PQconnectdb() in a loop, but I guess that's not good enough.
Yeah, something is obviously missing.. Are you guys on the exactly the
same Windows versions? WRT both version and servivepack. Anybody on x64
windows?
Another thing worth testing - check if the amount of shared memory used
makes a noticable difference. Try both very small and very large values.
I don't think the paged pool is the problem - I think it's the nonpaged
pool. Would be interesting to track that one in the failing case (using
performance monitor, up to the point where it fails). And the nonpaged
one is smaller... If that looks like it's the problem, it could be
helpful to do a pooltag trace on it (see for example
http://blogs.msdn.com/ntdebugging/archive/2006/12/18/Understanding-Pool-Consumption-and-Event-ID_3A00_--2020-or-2019.aspx)
//Magnus