From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: dynamic shared memory and locks |
Date: | 2014-01-06 19:54:00 |
Message-ID: | CA+TgmoayqJ2wtWiARkyJ_GM64DdU4uRO1F3e0=nwKVKbNW-ZMw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 6, 2014 at 2:48 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-01-06 19:58:16 | Re: [PATCH] Store Extension Options |
Previous Message | Tom Lane | 2014-01-06 19:53:53 | Re: truncating pg_multixact/members |