On Mon, Jan 6, 2014 at 2:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Well, I took a look at this and it turns out not to be very hard, so
>> here's a patch. Currently, we allocate 3 semaphore per shared buffer
>> and a bunch of others, but the 3 per shared buffer dominates, so you
>> end up with ~49k spinlocks for the default of 128MB shared_buffers. I
>> chose to peg the number of semaphores at 1024, which is quite small
>> compared to the current allocation, but the number of spinlock
>> allocations that can be in progress at any given time is limited by
>> the number of running backends. Even allowing for the birthday
>> paradox, that should be enough to run at least a few dozen backends
>> without suffering serious problems due to the multiplexing -
>> especially because in real workloads, contention is usually
>> concentrated around a small number of spinlocks that are unlikely to
>> all be mapped to the same underlying semaphore.
>
>> I'm happy enough with this way forward. Objections?
>
> -1 for the any_spinlock_held business (useless overhead IMO, as it doesn't
> have anything whatsoever to do with enforcing the actual coding rule).
Hmm. I thought that was a pretty well-aimed bullet myself; why do you
think that it isn't? I don't particularly mind ripping it out, but it
seemed like a good automated test to me.
> And I'd suggest defining NUM_SPINLOCK_SEMAPHORES in pg_config_manual.h,
> and maybe dropping SpinlockSemas() altogether in favor of just referencing
> the constant. Otherwise this seems reasonable.
As far as pg_config_manual.h is concerned, is this the sort of thing
you have in mind?
#ifndef HAVE_SPINLOCKS
#define NUM_SPINLOCK_SEMAPHORES 1024
#endif
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company