From owner-freebsd-performance@FreeBSD.ORG Tue Apr 10 10:56:38 2007 Return-Path: X-Original-To: performance@FreeBSD.org Delivered-To: freebsd-performance@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0C0BA16A403; Tue, 10 Apr 2007 10:56:38 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from smtp4.clear.net.nz (smtp4.clear.net.nz [203.97.37.64]) by mx1.freebsd.org (Postfix) with ESMTP id CCE9813C469; Tue, 10 Apr 2007 10:56:37 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from [192.168.1.11] (121-72-64-123.dsl.telstraclear.net [121.72.64.123]) by smtp4.clear.net.nz (CLEAR Net Mail) with ESMTP id <0JGA00HAI30OUE20@smtp4.clear.net.nz>; Tue, 10 Apr 2007 22:41:12 +1200 (NZST) Date: Tue, 10 Apr 2007 22:41:04 +1200 From: Mark Kirkwood In-reply-to: <20070226002234.GA80974@xor.obsecurity.org> To: Kris Kennaway Message-id: <461B69C0.4060707@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <20070226002234.GA80974@xor.obsecurity.org> User-Agent: Thunderbird 1.5.0.10 (X11/20070313) Cc: performance@FreeBSD.org, current@FreeBSD.org, pgsql-hackers Subject: Re: Anyone interested in improving postgresql scaling? X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2007 10:56:38 -0000 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. Cheers Mark