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>
index | next in thread | previous in thread | raw e-mail
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 lanehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25573.1176215022>