Date: Tue, 10 Apr 2007 13:21:50 +0200 From: Maxime Henrion <mux@FreeBSD.org> To: Mark Kirkwood <markir@paradise.net.nz> Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, performance@FreeBSD.org, current@FreeBSD.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: Anyone interested in improving postgresql scaling? Message-ID: <20070410112150.GC39474@elvis.mu.org> In-Reply-To: <461B69C0.4060707@paradise.net.nz> References: <20070226002234.GA80974@xor.obsecurity.org> <461B69C0.4060707@paradise.net.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070410112150.GC39474>