From owner-freebsd-performance@FreeBSD.ORG Tue Nov 23 02:34:59 2010 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FD87106564A; Tue, 23 Nov 2010 02:34:59 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F05E78FC15; Tue, 23 Nov 2010 02:34:58 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oAN2YuJl018060; Tue, 23 Nov 2010 02:34:57 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4CEB98D6.40902@freebsd.org> Date: Tue, 23 Nov 2010 10:35:02 +0000 From: David Xu User-Agent: Thunderbird 2.0.0.24 (X11/20100630) MIME-Version: 1.0 To: Ivan Voras References: <4CEA9C46.8010507@freebsd.org> <4CEB8AEF.7030202@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org Subject: Re: PostgreSQL performance 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, 23 Nov 2010 02:34:59 -0000 Ivan Voras wrote: > On 23 November 2010 10:35, David Xu wrote: >> Ivan Voras wrote: > >>> and the overall behaviour is similar - the processes spend a lot of time >>> in "sbwait" and "ksem" states. >>> >> Strange, the POSIX semaphore in head branch does not use ksem, it is >> based on umtx, there is no limit on POSIX semaphore, the only limit >> is process's address space which limits how many semaphores can be >> used. > > *shrug*; I don't know how it could be wrong - this PostgreSQL was > built from ports after I upgraded & booted 9-current. > > If it didn't use POSIX semaphores from HEAD, shared semaphores > wouldn't have worked, right? > It may work, but even it is shared in memory, it still enters kernel to do P/V operation.