Mark Kirkwood wrote:
> Kris Kennaway wrote:
> >If so, then your task is the following:
> >
> >Make SYSV semaphores less dumb about process wakeups. Currently
> >whenever the semaphore state changes, all processes sleeping on the
> >semaphore are woken, even if we only have released enough resources
> >for one waiting process to claim. i.e. there is a thundering herd
> >wakeup situation which destroys performance at high loads. Fixing
> >this will involve replacing the wakeup() calls with appropriate
> >amounts of wakeup_one().
>
> I'm forwarding this to the pgsql-hackers list so that folks more
> qualified than I can comment, but as I understand the way postgres
> implements locking each process has it *own* semaphore it waits on -
> and who is waiting for what is controlled by an in (shared) memory hash
> of lock structs (access to these is controlled via platform Dependant
> spinlock code). So a given semaphore state change should only involve
> one process wakeup.
Yes but there are still a lot of wakeups to be avoided in the current
System V semaphore code. More specifically, not only do we wakeup all
the processes waiting on a single semaphore everytime something changes,
but we also wakeup all processes waiting on *any* of the semaphore in
the semaphore *set*, whatever the reason we're sleeping.
I came up with a quick patch so that Kris could do some testing with it,
and it appears to have helped, but only very slightly; apparently some
contention within the netisr code caused problems, so that in some cases
the patch helped slightly, and in others it didn't.
The semaphore code needs a clean rewrite and I hope to take care of this
soon, as time permits, since we are heavy consumers of PostgreSQL under
FreeBSD at my company.
Cheers,
Maxime
