Date: Tue, 10 Apr 2007 10:23:42 -0400 From: Tom Lane <tgl@sss.pgh.pa.us> 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: [HACKERS] Anyone interested in improving postgresql scaling? Message-ID: <25573.1176215022@sss.pgh.pa.us> 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 <markir@paradise.net.nz> writes: > 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. Correct. The behavior Kris describes is surely bad, but it's not relevant to Postgres' usage of SysV semaphores. regards, tom lane
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25573.1176215022>